Visual Basic Q&A

Symptoms
Some data access objects in Visual Basic for Windows version 4.0 no longerhave the default “Name” property. Instead, these objects now have a defaultcollection. This change can lead to “Type Mismatch” (Error 13) or “InvalidArgument” (Error 3001) errors when attempting to run your code.
Resolution
To work around this problem, add the name of the property you want toreference.
For example, use this:

MsgBox Data1.Database.TableDefs(0).Name instead of this:

MsgBox Data1.Database.TablesDefs(0)

Symptoms
If you try to run Structured Query Language (SQL) against an Oracledatabase through Data Access Objects (DAO), you can encounter the followingerror:

Run-Time Error 3024
Couldn’t find file C:\Program Files\DevStudio\VB\<schema name>.mdb.This error occurs when you try to specify a schema name in your SQLstatement and you use DAO with Oracle. The <schema name> in the errormessage is whatever schema name you specified for the Oracle object youreference.
Resolution
If you add the dbSQLPassThrough option to the OpenRecordset method, thesample code in the MORE INFORMATION section of this article runs withouterror. You can use brackets ([ ]) around the table name in the SQL string toavoid the error as well:

sql = “SELECT * FROM [scott.emp]” Also, you can use an advanced data access technology, such as ActiveX DataObjects (ADO) to avoid this error.

Symptoms
When using the Data Access Objects (DAO), Remote Data Objects (RDO) or the ADO GetChunk method, on a long binary field of a Microsoft Access database, binary data may appear corrupt if the binary information previously stored was read from disk using a String (BSTR) variable instead of a Byte array. The problem occurs under one of the following conditions:
You recently upgraded your computer to Windows 98 or Windows NT version 4.0 SP4. Previously stored data now appears corrupt.
-or-You are using a shared database. The corruption occurs when the binary data was stored by clients running on Windows 95 or Windows NT 4.0 SP3, and then extracted by clients running Windows 98 or Windows NT 4.0 SP4 or vice versa.
Resolution
The problem is that the information stored to the database is mistakenly being converted to Unicode before being stored. The “corruption” occurs when reading the information from disk using the Visual Basic or Visual Basic for Applications Get statement.
By design, the Get statement relies on the data type of the variable to determine how the information should be read into Visual Basic. If you pass a String (BSTR) variable to the function, Visual Basic identifies the information as being a text string, and converts it to Unicode. However, since the data is binary and not text, this conversion corrupts the data before it is ever stored to the database.
Although binary data stored in Unicode format can be “decoded” in some cases, it requires that the Unicode symbol table used to map 1-byte ANSI characters to 2-byte Unicode characters be the same for both the conversion to and the conversion from Unicode. Due to the recent addition of the European Currency symbol, the symbol table for Windows 98 and Windows NT 4.0 SP4 is different from those used previously. These changes will have no effect on text strings, but can effect binary data mistakenly converted to Unicode.

Symptoms
If you try to dimension a Dynaset, Snapshot, or Table object variable andusing DAO 3.0 (Visual Basic version 4.0 data access objects), you willreceive this runtime error:

User-defined type not defined.If you replace the Dynaset, Snapshot, or Table object with the Object orRecordSet type and use methods such as CreateDynaset, CreateSnapshot, orOpenTable that are tied to the Dynaset, Snapshot, or Table types, you willreceive this error:

Feature not available.
Resolution
Visual Basic version 4.0 has replaced the older Dynaset, Snapshot, andTable objects with a single RecordSet object. This object can take on theattributes of any of the older three making it much more powerful andflexible.

Symptoms
When you first try to run an application that a Visual Basic 6.0 Setup package installed and that the Packaging and Deployment Wizard (PDW) created, you may receive the following error message:

Class not registered.
Looking for object with CLSID {00000010-0000-0010-8000-00AA006D2EA4}.
Resolution
This error occurs when the Visual Basic 6.0 project references the Microsoft Data Access Objects (DAO) 3.6 Object Library (DAO360.dll) and not DAO350.dll. The {00000010-0000-0010-8000-00AA006D2EA4} CLSID is associated with DAO350.dll.
When the intrinsic Data control’s Connect property is set to Access, and the application uses this Data control, the application requires that DAO350.dll is registered on the system. However, DAO350.dll is not included in the distribution package that the PDW creates because it is not referenced in the project.

Symptoms
After porting a Visual Basic 4.0 program that is written using DAO 3.0(Data Access Objects) to DAO 3.5, the error message:

“Argument Not Optional”will occur on the Update, Movelast, and CommitTrans methods. This does nothappen in Visual Basic 5.0.
Resolution
In DAO 3.0, the methods listed above do not use optional arguments. They douse optional arguments in DAO 3.5. This is a problem caused by adding theTyped Optional Parameter feature to OLE Automation. Only newer Automationcontrollers such as Visual Basic 5.0 are going to understand this. VisualBasic 4.0 can accept optional parameters only if they are of the Variantdata type. The optional arguments for the methods listed above are notVariant so it doesn’t recognize them as optional.