Hi all,

There doesn't seem to be a simple way to trace the ODBC calls from the
client side.

I'm trying to track down a problem in a crystal report with a date
parameter.
It started occurring after updating the client to OpenROAD 2006. Ingres Net
is 2006.
The developer has received an ODBC only patch from Ingres Support but it
hasn't solved the problem.
The date parameters are entered dd/mm/yyyy. An Ingres ODBC error is returned
something like YYYY is not a valid month.

Is server side tracing still the recommended approach?
I read trace point sc902 and printqry could be used.


Paul

Hi Paul,

You can turn on ODBC tracing on the client side by using the ODBC Data
Source Administrator (Start/Control Panel/Administrative Tools/Data
Sources (ODBC)/Tracing Tab).

Dave


--
thoda04

On/El 02/07/09 17:01, Paul White wrote/escribió:

To see what's going across the wire you can use OpenAPI and GCA tracing:
II_API_TRACE=5
II_GCA_TRACE=5
II_API_LOG=c:\api.log

This will need to be set in the environment before the application
starts. I am not sure the service side tracing will work as I guess the
"invalid" data is being rejected by the Ingres client. I am a bit
confused as to how the YYYY component can end up in the month position
unless there is a funky locale being used?

g


--
Grant Croker - Ingres PHP and Ruby maintainer
http://blogs.planetingres.org/grant
Generally, old media don't die. They just have to grow old gracefully.
Guess what, we still have stone masons. They haven't been the primary
purveyors of the written word for a while now of course, but they still
have a role because you wouldn't want a TV screen on your headstone.

Hi Paul,

Generally client-side tracing is best for these kinds of problems.

You may wish to create a system-level ODBC DSN definition in the ODBC
Administrator and see if that helps. If that doesn't work, you add
II_ODBC_TRACE to the API environment variables that Grant listed above.
See 'ODBC Driver - Tracing - Ingres Community Wiki'
(http://community.ingres.com/wiki/ODBC_Driver_-_Tracing) for more
details.

I suspect this is a known problem, though, for which a fix is
available. What is the value of ii.[hostname].config.date_alias?
INGRESDATE or ANSIDATE? What is the Ingres version on the server? What
is the value, if any, for II_DATE_FORMAT? If unset, the default is US,
which ought to accept MM/DD/YYYY.

If you execute "help [tablename] on the target table, what is the type
of the target column? Does your date variable include standard escape
sequence for dates, is it a straight string, such as "2009-12-25", or is
it a SQL_TYPE_DATE_STRUCT? What ODBC patch did you receive? If
unknown, what is the ODBC version of the Ingres driver?

Regards, Ralph


--
loera01

Hello Paul,

I also had these "...not a valid month..." errors when using the new
3.50.xx drivers against Ingres 9.0.x and Ingres 9.1.x Windows-based
servers. My workaround was to use the old 2.80.xx drivers for quite a
while.

Just a few days ago I discovered after upgrading the server side to
9.2.0 + P13354 the 3.50.xx drivers all of a sudden also worked.

Regards
Gerhard


--
gerhard.hofmann (AT) planat (DOT) de
------------------------------------------------------------------------
gerhard.hofmann (AT) planat (DOT) de's Profile: http://community.ingres.com/forum/member.php?userid=857
View this thread: http://community.ingres.com/forum/sh...ad.php?t=10894

Hi Paul,

There have been a number of issues in both the Database and ODBC around
dates since the addition of ANSI Date support in 9.1. I think we've
gotten to the root of all the problems so I recommend you contact
support to get the latest DBMS patch for your platform as well as the
latest ODBC driver patch. Most of the issues were eventually tracked
down to the DBMS but not all which is why I recommend getting the latest
patches for both.

Regards,
Teresa


--
teresa