ODBC call failed

[harriettbird]

A client has queries that run off linked tables - Sybase. If the queries have
parameter prompts, immediately the ODBC call failed error is displayed - no
error number. If the prompts are removed and the criteria is manually entered
into the query design window, the query runs. The same error is displayed on
new queries based on linked tables. Parameter queries run if based on
non-linked tables. Any suggestions??? Access 2K/Win2K

 

[Rick Brandt]

A client has queries that run off linked tables - Sybase. If the
queries have parameter prompts, immediately the ODBC call failed
error is displayed - no error number. If the prompts are removed and
the criteria is manually entered into the query design window, the
query runs. The same error is displayed on new queries based on
linked tables. Parameter queries run if based on non-linked tables.
Any suggestions??? Access 2K/Win2K

Have you tried explicitly setting the DataTypes in the parameters dialog of
the query in design view? It might be that the "assumed" type that
Access/Jet is using is causing a problem.

 

[harriettbird]

Sorry Rick, I'm not sure how to do what you are suggesting. Can you explain
more? Thanks!

 

[Rick Brandt]

Sorry Rick, I'm not sure how to do what you are suggesting. Can you
explain more? Thanks!

Lets say you have a parameter marker to filter on a date [Enter Start Date].
Access will usually be able to figure out that this should be a date based
on what the user enters when prompted. However you can actually include in
the design of the query that this parameter should be treated as a DateTime.

With the query opened in Design view right-click in the gray area at the top
and choose "Parameters" from the resulting menu. That will open the
parameters dialog which has two columns "Parameter" and "Data Type".

On the first row of that dialog you enter [Enter Start Date] in the first
column and Date/Time in the second. This way you are pre-informing Access
about the DataType and you are in control rather than relying on whatever
assumption Access might make. This is actually required in Crosstab
queries, but is normally not required in most other queries (but always a
good idea anyway).

I don't have any idea if this will solve your problem, but this might be a
case where explicitly defining the parameter type might be helpful.