3
|
|
3 |
|
|
The LA Fox Developer Newsletter
|
|
April2000
|
|
ADO Jumpstart for Microsoft Visual FoxPro Developers
(Ed. Note: Reprinted with the author’s full permission. This is the third installment of a multi-part article begun in February’s
LA Fox Developer.]
Along with GetChunk, examine the AppendChunk method. The
first
time this method is called for a field, it overwrites any data in the field. Successive calls then append the data, until pending edits are cancelled or updated. The following code illustrates how this method works:
For x = 1 To 100
oRecordset.Fields("notes").AppendChunk(Str(x)+Chr(10) 0)+Chr(1 3)) Next x
Both the GetChunk and AppendChunk methods are ideal for dealing with low memory scenarios.
The Attributes Property
An attribute specifies the characteristics of something. As a person, you have many attributes, eye color, height, weight, and so forth. In the OOP world, objects have many attributes. Most of the time, attributes are exposed in the form of properties. A Visual FoxPro form has several properties such as Width, Height, and BackColor, just to name a few. The same is true for objects in ADO. Sometimes, however, it is not convenient to have a one-to-one correspondence between attributes and properties. Often, you can pack large amounts of information into a smaller space through the power of setting bits. A bit is much like a switch. It is either on or off or
1
or 0. If you string these bits together, you gain the ability to store multiple values in a small space. This is how the Attributes property works.
The Connection, Parameter, Field, and Property objects all have an Attributes property. If you have never worked with bit opera- Lions before, working with this property can be quite challenging. In some situations, as is the case with the GetChunk and AppendChunk methods, you will need to refer to the Attributes property of the Field object to determine whether those methods are available.
Using the Field object to illustrate how the Attributes property
Norks, you can associate the following attributes with a Field
Dbject and its associated binary values:
adFldMayDefer—lndicates that the field contents are retrieved Dnly when referenced—0x00000002
adFldupdateable—lndicates that the field can be updated— Dx00000004
adFldUnkownupdateable—lndicates that the provider does riot know whether the field is updateable—0x00000008
|
adFldFixed—lndicates that the field contains fixed length data—Ox000000l 0
adFldlsNullable—lndicates that the field can accept a null value dunng a write operation—0x00000020
adFldMayBeNullable—Indiates that the field may contain a null value—0x00000040
adFldlong—lndicates that the field contains long binary data and that the GetChunk and AppendChunk methods can be used—0x00000080
adFldRowlD—Indicates that the field contains a row ID and cannot be updated. This does not relate to a field that may contain the identity value or some other auto-incrementing value. Rather, it relates to a ROW ID that is unique across the database. Oracle has this feature—Ox00000lOO
adFldRowVersion—Indicates whether the field indicates the version of the row. For example, a SQL TimeStamp field may have this attribute set—0x00000200
adFldCachedDeferred—lndjcates that once this field has been read, future references will be read from the cache— Ox0000l 000
Usually, more than one of these attributes are present at any given time. Yet the Attributes property is a single value. Using the Employees table Notes field as an example, you will see that the Attributes property yields a value of 234. The value 234 represents the sum of the attributes for that field. For example, nullable and long attributes have decimal values of 32 and 128 respectively. This means that the Attributes property evaluates to 160. This works like the Windows Messagebox dialog box with regard to specifying the icon and types of buttons that are present.
Knowing that the Attributes property is a sum of the attributes of
a Field object does not help in determining whether a specific
attribute is present. This is where understanding bit operations
comes in handy. The first step is to convert the sum (such as
234, above) into a binary equivalent:
11101010
Working from right to left, (or from the least significant bit to the most significant)—and beginning with zero, see that bits 1, 3, 5, 6, and 7 are set, (indicated by their values of I in those positions). Bits 0, 2, and 4 are not set. The next step is to determine whether a field is “long.”
To determine whether a field is a long field, we must first convert the adFldLong constant, which specifies which bit if set, indicates that the field is long. The adFldLong constant has a hex value of 0x00000080. This translates into a decimal value of 128. The following is the binary equivalent:
10000000
|
|
Page 3
|
|
|
3 |
|