ACC2002: Ignored MaxScanRows Setting May Cause Improper Data Types in Linked Tables (282263)
The information in this article applies to:
This article was previously published under Q282263 Advanced: Requires expert coding, interoperability, and multiuser skills.
This article applies only to a Microsoft Access database (.mdb).
SYMPTOMS
After you run Visual Basic for Applications code to create a linked table from a text file, you notice #Num! in one or more records.
CAUSE
One or both of the following are true:
- The following registry key is set to zero:
HKey_Local_Machine\Software\Microsoft\Jet\4.0\Engines\Text\MaxScanRows
- You have a Schema.ini file with the following entry:
If you have MaxScanRows set to zero, either in the registry or in the Schema.ini file, any tables that you link programmatically may contain fields with improper data types. This is because setting MaxScanRows to zero causes the entire table to be scanned in order to determine the data type of the fields. When this happens, the data type is set according to the majority type in the field. Consequently, if most of the fields contain numbers and some contain text, for example, the field is defined in Access as having the data type of Number, making the text entries show #Num!.
RESOLUTION
This issue does not occur if you link by using the Text Import Wizard. However, if you must create the link in code, you can define the data type for one or more fields in a Schema.ini file. In the following example, the first column is set to a data type of Char:
[Test.txt]
Format=CSVDelimited
ColNameHeader=false
MaxScanRows=0
CharacterSet=ANSI
Col1=ID Char Width 3
STATUSMicrosoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
Modification Type: | Major | Last Reviewed: | 11/6/2003 |
---|
Keywords: | kbbug kbnofix KB282263 |
---|
|