Errata

Seems to be a superfluous underscore in C++ example, which generates a compiler
ignore for the rename.

P.S. I also get a Compiler warning for this:
d:9781565924154debugmsado15.tlh(409) : warning C4146: unary minus operator applied to
unsigned type, result still unsigned

"&" is not a bitwise operator in VB but a concatenation operator. The "And" is both a
bitwise and a logical operator in VB.

The line on the top of page 100 should read:
If (rst.State And adStateOpen) Then rst.Close

("&" is a bitwise operator and "&&" is a logical operator in JavaScript, Java, and
C++, etc.)

Using method on page 100 to check if the state is closed would open up another can of
worms.

If 9781565924154Rs.State And adStateClose Then
' This would never be executed
' because it would never evaluate to True (non-zero)
End If

If (bitState And bitTest) = bitTest Then
' This would work if you were testing to see
' if a particular bit was on but would not work
' if you were tying to see if that bit was off
End If

If (bitState And 0) = 0 Then
' This statement would always execute thereby rendering
' the if block worthless
End If

If 9781565924154Rs.State = adStateClosed Then
' This will work provided each state is mutually exclusive.
' Or, if you really wanted to test for a simply closed recordset.
End If

Since the states are numbered 0, 1, 2, 4, 8, rather than say 0, 1, 2, 3, 4, I would
tend to think they are not mutally exclusive. For example, I can picture a recordset
being open and fetching at the same time. I can also picture a recordset being closed
and in the process of connecting.

If 9781565924154Rs.State = adStateOpen Then
' Might give an unexpected result if the state was both open
' and fetching when all you cared about was whether the
' recordset was open or not.
End If

Each programming situation would have to be examined independently. The example on
page 100 would be fine as:

If (rst.State And adStateOpen) Then rst.Close

Error : Until
Correction : Loop

The first 2 lines of page 118 describe the code example at the bottom of page 117 as
having "a call to the MoveLast method" that "moves the record pointer to the end of
the recordset."

In fact the code example at the bottom of page 117 doesn't have a call to the
MoveLast method at all.

in the description of the adCmdTableDirect value. In the second sentence

"This value is very similar to that of adCmdFile except that the ..."

It looks like "adCmdFile" should be "adCmdTable".

the page);
sSource proberty asignment results in invalid 86th character, which is the ; at the
end of the fourth line of code. Should be:
& " APPEND (TABLE [Orders Details] "

problems in the code. Fortunately, the shaping code worked correctly!

In the PopulateOrderDetailInformation method, line 8, I removed
"rstOrderDetails" from the beginning of the line.

In the Form_Unload method (page 230), line 10, I changed rst to rstCustomers.

In the example listed for Field.Name it reads a set value= field.GetChunk(NumBytes).
I think it should read fieldName = field.Name.

mistake.
Under the Recordset.CursorType Property, it reads
"recordset.CursorLocation = cursorLocation"
I'm sure you meant
"recordset.CursorType = cursorType"

The note section which is describing the recordset.GetRows method actually pertains
to the Recordset.Find method, which is listed on the opposite page. The note, which
reads "Not all providers support the Find method." appears to be meant for
Recordset.Find, as there is no mention on relying on .Find using GetRows.

Default value for CursorType is said to be
adLockReadOnly
which is not a CursorTypeEnum

HAVING (COUNT(Make) < 1);

the '<' should be a '>'

In the query, the table should be Sales, not Employees