M
MyndPhlyp
I am about to completely lose what is left of my poor mynd! The historical
dissertation gets rather verbose, so I hope you can wade through it all. I
really need some help on this one or I'm looking at rewriting all my hard
work in something else (wasting probably a month or more).
(If you want to run and hide now, the error message is "The decimal field's
precision is too small to accept the numeric you attempted to add." I
haven't yet found any real solution out there including MS's KB saying the
problem was first fixed in Jet v4.0 SP6 ... and I'm running Jet v4.0 SP8.)
All the tech tips I pulled up with Google seem to wander off to no solution.
I found one ancient newsgroup posting left unanswered. I've really been
trying to research and resolve this problem.
I'm using Access 2000 on a Win2K Pro with MDAC v2.8 and, as already
mentioned, Jet v4.0 SP8. All Connections and Recordsets are ADODB. The
destination table is a linked table originating from a FoxPro v3 database.
(Yeah, I know it's an antique, but I have to play the cards dealt.)
The link connection to the FoxPro tables is done through an ODBC DSN using
the "Microsoft Visual FoxPro Driver" (v6.01.8630.0, if it really matters).
The ODBC DSN is using the "Database type" of "Visual FoxPro database(.DBC)"
rather than the "Free Table directory." The Driver options are Collating
sequence => Machine; Exclusive => Off; Null => Off; Deleted => On; Fetch
data in background => Off. According to several MS KB articles, the "Visual
Foxpro database" option is the only method available. Just to make matters
worse, it appears MS is letting FoxPro die a slow death.
Using "Visual FixPro database (.DBC)" is required as it is the only way
Access will allow me a write enabled linked table. "Null = Off" is required
because old FoxPro v3 tables don't like fields populated with Null values.
I've tried programmatically building a Connection and relinking the tables
(and just linking them as new tables) using some ADOX methods, but kept
getting an error saying it "Could Not Find Installable ISAM". (There is no
ISAM driver for FoxPro anymore.) (MS KB 209805, 225861)
So ... I went back to ADO and CurrentProject.Connection.
With the FoxPro tables linked (and write enabled), I'd do something like:
Dim cnLocal as New ADODB.Connection
Dim rsMyTable as New ADODB.Recordset
Set cnLocal = CurrentProject.Connection
rsMyTable.CursorLocation = adUseClient
rsMyTable.Open "MYTABLE", cnLocal, adOpenDynamic, adLockPessimistic,
adCmdTable
With rsMyTable
.AddNew
!thisfield = thisValue
!thatfield = thatValue
.Update
End With
Everything runs fine until I hit one record where the value I intend to
inject is the numeric 240 originating from a column defined as Decimal with
a Precision of 9 and a Scale of 5. (Smaller numeric values go through just
fine, but I do not know precisely where the majik line of death is.)
The destination FoxPro column (by Access's definition) is Decimal with a
Precision of 11 and a Scale of 9.
Last time I checked, 240 fits well within the confines of the column
properties.
Just for grins, I went to the third-party application that actually uses the
FoxPro database, brought up the appropriate transaction form and updated a
record with the numeric value 240 just to prove the FoxPro database would
accept the value. Life was good, so I thought.
Going back to Access 2000, I brought up the table data, scrolled down to the
record and found "#Error" across all the columns of that one record. If I
let Access camp out with that record displayed for a length of time
(minutes), it would eventually burp out the error message mentioned at the
top.
Since Connection.Execute will process the basic SQL commands, I tried the
longhand approach. Leaving the recordset closed, I crafted an INSERT
statement and started pushing in records that way.
Again, life was fine ... until I reached that one entry with a numeric value
of 240, at which point I got the error message again.
I took the time to check the version of each and every DLL in the Jet v4.0
SP8 KB article (MS KB 239114). Every one checks out except:
Dao360.dll should be v3.60.8025.0 (is higher at v3.60.8618.0)
Msexcl40.dll should be v4.0.8015.0 (is higher at v4.0.8618.0)
Msjet40.dll should be v4.0.8015.0 (is higher at v4.0.8618.0)
Msjetoledb40.dll should be v4.0.8015.0 (is higher at v4.0.8227.0)
Msjint40.dll should be v4.0.8015.0 (is LOWER at v4.0.6508.0)
Msjtes40.dll should be v4.0.8015.0 (is higher at v4.0.8618.0)
The one that I suspect is MSJINT40.DLL. According to KB 239114, it is from
Jet v4.0 SP7. Reapplying Jet SP8 and/or MDAC v2.8 does nothing to upgrade
the version of this file.
I would really appreciate it if some knowledgeable individual here could
help me resolve this roadblock.
dissertation gets rather verbose, so I hope you can wade through it all. I
really need some help on this one or I'm looking at rewriting all my hard
work in something else (wasting probably a month or more).
(If you want to run and hide now, the error message is "The decimal field's
precision is too small to accept the numeric you attempted to add." I
haven't yet found any real solution out there including MS's KB saying the
problem was first fixed in Jet v4.0 SP6 ... and I'm running Jet v4.0 SP8.)
All the tech tips I pulled up with Google seem to wander off to no solution.
I found one ancient newsgroup posting left unanswered. I've really been
trying to research and resolve this problem.
I'm using Access 2000 on a Win2K Pro with MDAC v2.8 and, as already
mentioned, Jet v4.0 SP8. All Connections and Recordsets are ADODB. The
destination table is a linked table originating from a FoxPro v3 database.
(Yeah, I know it's an antique, but I have to play the cards dealt.)
The link connection to the FoxPro tables is done through an ODBC DSN using
the "Microsoft Visual FoxPro Driver" (v6.01.8630.0, if it really matters).
The ODBC DSN is using the "Database type" of "Visual FoxPro database(.DBC)"
rather than the "Free Table directory." The Driver options are Collating
sequence => Machine; Exclusive => Off; Null => Off; Deleted => On; Fetch
data in background => Off. According to several MS KB articles, the "Visual
Foxpro database" option is the only method available. Just to make matters
worse, it appears MS is letting FoxPro die a slow death.
Using "Visual FixPro database (.DBC)" is required as it is the only way
Access will allow me a write enabled linked table. "Null = Off" is required
because old FoxPro v3 tables don't like fields populated with Null values.
I've tried programmatically building a Connection and relinking the tables
(and just linking them as new tables) using some ADOX methods, but kept
getting an error saying it "Could Not Find Installable ISAM". (There is no
ISAM driver for FoxPro anymore.) (MS KB 209805, 225861)
So ... I went back to ADO and CurrentProject.Connection.
With the FoxPro tables linked (and write enabled), I'd do something like:
Dim cnLocal as New ADODB.Connection
Dim rsMyTable as New ADODB.Recordset
Set cnLocal = CurrentProject.Connection
rsMyTable.CursorLocation = adUseClient
rsMyTable.Open "MYTABLE", cnLocal, adOpenDynamic, adLockPessimistic,
adCmdTable
With rsMyTable
.AddNew
!thisfield = thisValue
!thatfield = thatValue
.Update
End With
Everything runs fine until I hit one record where the value I intend to
inject is the numeric 240 originating from a column defined as Decimal with
a Precision of 9 and a Scale of 5. (Smaller numeric values go through just
fine, but I do not know precisely where the majik line of death is.)
The destination FoxPro column (by Access's definition) is Decimal with a
Precision of 11 and a Scale of 9.
Last time I checked, 240 fits well within the confines of the column
properties.
Just for grins, I went to the third-party application that actually uses the
FoxPro database, brought up the appropriate transaction form and updated a
record with the numeric value 240 just to prove the FoxPro database would
accept the value. Life was good, so I thought.
Going back to Access 2000, I brought up the table data, scrolled down to the
record and found "#Error" across all the columns of that one record. If I
let Access camp out with that record displayed for a length of time
(minutes), it would eventually burp out the error message mentioned at the
top.
Since Connection.Execute will process the basic SQL commands, I tried the
longhand approach. Leaving the recordset closed, I crafted an INSERT
statement and started pushing in records that way.
Again, life was fine ... until I reached that one entry with a numeric value
of 240, at which point I got the error message again.
I took the time to check the version of each and every DLL in the Jet v4.0
SP8 KB article (MS KB 239114). Every one checks out except:
Dao360.dll should be v3.60.8025.0 (is higher at v3.60.8618.0)
Msexcl40.dll should be v4.0.8015.0 (is higher at v4.0.8618.0)
Msjet40.dll should be v4.0.8015.0 (is higher at v4.0.8618.0)
Msjetoledb40.dll should be v4.0.8015.0 (is higher at v4.0.8227.0)
Msjint40.dll should be v4.0.8015.0 (is LOWER at v4.0.6508.0)
Msjtes40.dll should be v4.0.8015.0 (is higher at v4.0.8618.0)
The one that I suspect is MSJINT40.DLL. According to KB 239114, it is from
Jet v4.0 SP7. Reapplying Jet SP8 and/or MDAC v2.8 does nothing to upgrade
the version of this file.
I would really appreciate it if some knowledgeable individual here could
help me resolve this roadblock.