in reply to Obtaining SQL updates for application to another database

Thanks for all your suggestions. It seems that the consensus is to go with option 1 i.e. hooking DBI (trace). A problem I have found with DBI_TRACE is that it is truncating the SQL, hence is not usable in this case.

jZed metioned the SQL flag bit in the DBI_TRACE level - something I was not aware of. Even if this is not available cross-platform, there is no reason why it could not be implemented for a given DBD - in my case DBD::Sybase.

I know that the SQL_TRACE environment variable does a similar job for Roguewave (object persistence layer). This has worked well for me diagnosing problems with said legacy app, which uses Roguewave dbtools. I will pursue this option with the sybperl list (which is used to support DBD::Sybase).

--
I'm Not Just Another Perl Hacker

  • Comment on Re: Obtaining SQL updates for application to another database

Replies are listed 'Best First'.
Re^2: Obtaining SQL updates for application to another database
by mpeppler (Vicar) on Apr 06, 2005 at 16:04 UTC
    I haven't worked on implementing the specifics of the DBI_TRACE bits in DBD::Sybase, so that may not work for you.

    There are a couple of Sybase-specific alternatives: You could use Ribo to capture incoming SQL requests, you could set up auditing on the server and extract the appropriate SQL requests, and you could also use things like the Sybase Replicator (the java light weight replication system included in ASE 12.5.x) to keep a remote table in sync.

    Update Having re-read the original question I see that the "replicator" option is not at all useful here. However, the other two (and in particular Ribo) could be used fairly easily.

    Michael