Почему чрезвычайно изредка будет один из кислородных конвертеров/ВФ быть верным для новой непустой записей

Question

set recordsetname = databasename.openrecordset(SQLString) 
    if recordsetname.bof <> true and recordsetname.eof <> true then 
    'do something 
    end if 

2 вопроса:

1. выше тест может оценить ложь неправильно, но только крайне редко (I» у меня был один скрытый в моем коде, и он провалился сегодня, я считаю, что впервые за 5 лет ежедневного использования - вот как я его нашел). Почему очень редко одно из bof/eof истинно для непустого набора записей. Кажется настолько редким, что я удивляюсь, почему это происходит вообще.

2. Является ли это несложный замена:

   if recordsetname.bof <> true or recordsetname.eof <> true then 
   

Редактировать, чтобы добавить детали код:

Клиенты имеют заказов, каждый заказ начинается с BeginOrder пункта и заканчиваться EndOrder и между ними находятся элементы в заказе.

SQL, является:

' ids are autoincrement long integers ' 
SQLString = "select * from Orders where type = OrderBegin or type = OrderEnd"   

Dim OrderOpen as Boolean 
OrderOpen = False 

Set rs = db.Openrecordset(SQLString) 
If rs.bof <> True And rs.eof <> True Then 
    myrec.movelast 
    If rs.fields("type").value = BeginOrder Then 
     OrderOpen = True 
    End If 
End If 

If OrderOpen F False Then 
    'code here to add new BeginOrder Item to Orders table ' 
End If 

ShowOrderHistory 'displays the customer's Order history ' 

В этом случае, который выглядит это это

BeginOrder 
Item a 
Item b 
... 
Item n 
EndOrder 

BeginOrder 
Item a 
Item b 
... 
Item n 
EndOrder 

BeginOrder 
Item a 
item b 
... 
Item m 

BeginOrder  <----should not be there as previous order still open 

Answer 1

Узор Я всегда использовал это:

Set rs = db.OpenRecordset(...) 

Do while Not rs.EOF 

    ' Rest of your code here. 

    rs.MoveNext 
Loop 

Я никогда не видел этого терпеть неудачу (все же!). Это описано здесь: How to: Detect the Limits of a DAO Recordset

В качестве альтернативы могут быть интересны ловушки VBA Аллена Брауна: Working with Recordsets.

Answer 2

В документации четко сказано, что, если вы откроете Recordset, который не имеет записей:

• BOF будет истинным
• EOF будет истинным
• RecordCount будет 0

Для непустого Recordset, ни BOF, так и EOF верны, пока вы не перейдете за первую или последнюю запись.

Может быть, кто-то еще мог добавить/удалить запись в одну из таблиц в наборе записей, который вы только открываете и меняете набор результатов?
Это может быть результат гонки.

Вместо использования BOF или EOF, вы можете проверить на Recordcount: это всегда 0 если записи пусты.
Если набор записей не пуст, он, как правило, возвращает 1 сразу после открытия набора записей; Recordcount не является дорогостоящей операцией в этом случае.
Единственный способ действительно вернуть номер, чтобы указать номер MoveLast, прежде чем звонить Recordcount, чтобы заставить все записи быть загружены.

Обычно, если мне нужно перебирать в результирующем только для чтения моды:

Dim db as DAO.Database 
Dim rs as DAO.RecordSet 

Set db = CurrentDB() 
Set rs = db.OpenRecordSet("...", dbOpenForwardOnly) 
If Not (rs Is Nothing) Then 
    With rs 
     Do While Not .EOF 
      ' Do stuff ' 
      .MoveNext 
     Loop 
     .Close 
    End With 
    Set rs = Nothing 
End If 
Set db = Nothing 

Если мне не нужно перебирать записи, но просто проверить, если что-то было возвращено:

Set rs = db.OpenRecordSet("...", dbOpenForwardOnly) 
If Not (rs Is Nothing) Then 
    With rs 
     If .RecordCount > 0 Then 
      ' We have a result ' 
     Else 
      ' Empty resultset ' 
     End If 
     .Close 
    End With 
    Set rs = Nothing 
End If 
Set db = Nothing 

Это довольно оборонительно, и вам приходится приспосабливаться к вашим обстоятельствам, но он работает правильно каждый раз.

Что касается вашего 2 вопроса, тестирование (BOF Или EOF) после открытия записей должны быть более надежными, чем версия And, хотя я бы использовать Recordcount сам.

Редактировать после вашего пересмотренного вопроса:

Из кусочка коды вы добавили на ваш вопрос, я вижу несколько вопросов, главный из которых, что ваш SQL заявление отсутствует и ORDER BY положения.
Проблема заключается в том, что вы ожидаете, что набор результатов будет в Begin Order, а затем в последовательности End Order, но ваш SQL-запрос не гарантирует этого.
В большинстве случаев, так как вы используете автоинкрементный как ID, ядро ​​базы данных будет возвращать данные в этом естественном порядке, но нет никакой гарантии, что:

• Это всегда будет происходить таким образом
• Что исходные данные были сохранены в ожидаемой последовательности, что привело к идентификаторам, которые находятся в «неправильном» порядке.

Итак, всякий раз, когда у вас есть ожидания относительно последовательности набора результатов, вы должны явно заказать его.

Я хотел бы также реорганизовать этот бит кода:

' ids are autoincrement long integers ' 
SQLString = "select * from Orders where type = OrderBegin or type = OrderEnd"   

Dim OrderOpen as Boolean 
OrderOpen = False 

Set rs = db.Openrecordset(SQLString) 
If rs.bof <> True And rs.eof <> True Then 
    myrec.movelast 
    If rs.fields("type").value = BeginOrder Then 
     OrderOpen = True 
    End If 
End If 

В отдельную функцию аналогично:

' Returns true if the given CustID has a Open Order, ' 
' false if they are all closed.' 
Public Function IsOrderOpen(CustID as Long) As Boolean 
    Dim result as Boolean 
    result = False 

    Dim sql as String 
    ' Here I assume that the Orders table has a OrderDateTime field that ' 
    ' allows us to sort the order in the proper chronological sequence ' 
    ' To avoid loading the complete recordset, we sort the results in a way ' 
    ' that will return the last used order type as the first record.' 
    sql = sql & "SELECT Type " 
    sql = sql & "FROM Orders " 
    sql = sql & "WHERE ((type = OrderBegin) OR (type = OrderEnd)) " 
    sql = sql & "  AND (CustID=" & CustID & ")" 
    sql = sql & "ORDER BY OrderDateTime DESC, Type DESC;" 

    Dim db as DAO.Database 
    Dim rs as DAO.Recordset 
    Set db = CurrentDB() 
    Set rs = db.Openrecordset(sql, dbOpenForwardOnly) 

    If Not (rs Is Nothing) Then 
     If rs.RecordCount > 0 Then 
      result = (rs!type = BeginOrder) 
     End If 
     rs.Close 
    End If 

    Set rs = Nothing 
    Set db = Nothing 

    IsOrderOpen = result 
End Function 

Это сделало бы все это немного более надежным.

Answer 3

Это DAO, верно? Я больше человек ADO, но у меня есть обстоятельства (dynaset?), Где вам нужно ориентироваться в EOF, чтобы оценить окончательное количество строк. Может ли это быть в этом состоянии, что EOF истинно, BOF является ложным (потому что он еще не был перемещен), но как только BOF перемещается, это верно (очевидно), и EOF остается правдой. Предположительно, начальное состояние, когда ожидаются нулевые строки, - это , предположительно, чтобы быть мгновенным, но один раз в пять лет, связанный с инцидентом, связанным с уродством, означает, что вы захватили его в действительно раннем начальном состоянии?

Answer 4

Ответ @Renaud Bompuis достаточно хорош. Позвольте мне подчеркнуть, что DAO Recordcount никогда не равен нулю для непустого набора записей, и это единственное, что я когда-либо испытывал при определении того, вернул ли записи набор записей. Я использую .EOF для прокрутки записей, но не начинайте выполнять записи до тех пор, пока я не проверил, если будут возвращены записи.

Answer 5

Here's a possible solution

Это может быть, что ваша форма или модуль получил повреждения. Экспортировать/импортировать затронутый модуль или форму или попробовать параметр/декомпилировать. В моем случае запрос возвращался пустым, когда он не должен был, но я думаю, что основная проблема может быть аналогичной.

Answer 6

я иногда попадались точно такой же ошибка доступа (было это сегодня в Access 2007, связанного с SQL сервера заднего конца) где оператор

если rst.bof и rst.eof

вычисляет false, несмотря на то, что первое представляет пустой набор записей. Когда это произошло, началось VBA, и отладчик в непосредственной панели показал, что действительно rst.bof был true, а rst.eof был прав, так что это похоже на миллисекунду, а затем исправлено, но после того, как вы проверили логику.