Re: error messages practically worthless
- From: "Dave Dawson" <selfgov2000@xxxxxxxxxx>
- Date: Fri, 15 Jul 2005 11:55:05 -0600
Thanks, '69 Camaro, for trying with the limited information I gave. I was
very frustrated. I guess I'm no less frustrated now, but have determined
more.
If some representative from Micro$oft is reading this, I would like to have
an explanation for what follows. If it has been my ignorance, you have my
appology in advance. If, however, it is because of some inadequacy, and or
apathy, on the part of Micro$oft that I have lost many hours of
productivity, I want at least an appology from Micro$oft.
In the code below (rstAccExtract.Open statement), if I merely change the
name of the table in the mdb to "table1" (as well as the reference to it in
the .open statement) it opens fine. (I had learned this by trial and error
before getting this message.) It also behaves perfectly well in the user
interface with the "extract" name. Also, the "extact" table name works just
fine in the rstExtract.Open statement.
How should I have known that or been reasonably expected to have found the
information in M$ documentation and Help files? The reference sent below by
'69 Camaro doesn't seem to refer to table names. It talks about making query
statements. Well in this case, Access itself makes the query statement. Why
isn't Access smart enough to recognize the reserved word in the table name
and bracket it? Is it too much to expect that a reasonably intelligent
person should not have to lose valuable productivity to crap such as this?
As I said above, if this is just the result of my ignorance, please
disregard and accept my appologies.
Does Micro$oft really care if I lose valuable hours of productivity using
their applications??????
Disgusted Dave
****************
Dim cnnFLDCW, cnnCurPrj As ADODB.Connection
Dim rstExtract, rstStatus, rstTempFAT, rstAccExtract As ADODB.Recordset
Dim cmdUpdate, cmdSelect As ADODB.Command
Dim blnNoExtract As Boolean
Dim lngStatResult, lngRecAff As Long Dim strUpdate As String
Set cnnFLDCW = New ADODB.Connection
Set cnnCurPrj = New ADODB.Connection
Set rstExtract = New ADODB.Recordset
Set rstAccExtract = New ADODB.Recordset
Set cmdSelect = New ADODB.Command
cnnCurPrj.Open (CurrentProject.Connection)
rstAccExtract.Open "extract", cnnCurPrj, adOpenStatic, adLockReadOnly,
adCmdTable
cnnFLDCW.Open ("provider=vfpoledb;;data source=c:\FLDCW\;")
rstExtract.Open "Extract", cnnFLDCW, adOpenStatic, adLockReadOnly,
adCmdTable
Stop
*********************
"'69 Camaro" <ForwardZERO_SPAM.To.69Camaro@xxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:C15EDC34-942E-4DDD-80D2-5915CE556D14@xxxxxxxxxxxxxxxx
> Hi, Dave.
>
>> It would seem to me that when a recordset open generates an error, there
>> should be more information forthcoming than "method 'open' of object
>> '_recordset' failed".
>
> This is a generic error message for when an internal recordset object
> can't
> be created using whichever data access library is assigned. There are
> many
> ways to get this error message, such as typographical errors, incorrect
> precedence of library files, missing or corrupted library files, outdated
> MDAC files, et cetera. However, without your telling us the context of
> this
> error message, we'll have to read your mind and hope it's Disgusted Dave's
> mind we're reading and not someone else's. If it's not your mind, then
> I'm
> sure that more information will be forthcoming so that we may help you.
>
> Here goes:
>
> "You are using VBA code to create and open a Recordset, and you have a
> malformed SQL statement due to a field name that was valid in Jet 3.5 (for
> Access 97), but is a reserved word in ANSI SQL-92, which Jet 4.0 (for
> Access
> 2003) uses. To fix this, you need to either place brackets around this
> field
> name in the query or change the field name in the table to something else,
> and then use that new name in the query. Since you haven't pasted the VBA
> code or the SQL statement into your message, we won't point out the errant
> field name, but you can look at the following Web page and find it on the
> list of Jet 4.0 reserved words:"
>
> http://support.microsoft.com/?id=321266
>
> HTH.
>
> Gunny
.
- Follow-Ups:
- Re: error messages practically worthless
- From: '69 Camaro
- Re: error messages practically worthless
- References:
- error messages practically worthless
- From: Dave Dawson
- RE: error messages practically worthless
- From: '69 Camaro
- error messages practically worthless
- Prev by Date: Re: export - no leading zeros
- Next by Date: Re: Why do blank fields, when exported to Excel appear not blank?
- Previous by thread: RE: error messages practically worthless
- Next by thread: Re: error messages practically worthless
- Index(es):
Relevant Pages
|
Loading