>
> "Jeff Urlwin" <[EMAIL PROTECTED]> writes:
>
> > > I recently upgrading a Win32/Activestate system to
> > > ActiveState build 806 with DBD::ODBC 1.05 and DBI 1.37. I
> > > find that I now get errors of the following type when I try
> > > to create a view over DBD::Proxy from my Linux box.
> > >
> > > DBD::Proxy::db do failed: Server returned error: Failed to
> > > execute method CallMethod: Describe failed during
> > > DBI::ProxyServer::st=HASH(0x1f00888)->FETCH(NUM_OF_FIELDS)
> > > at R:/Perl/site/lib/DBI/ProxyServer.pm line 287.
> > >
> > > It would appear that NUM_OF_FIELDS fetched after the
> > > execute() for a CREATE VIEW statement crashes out. I am able
> > > to reproduce this with a simple script running on the Win32 box...
>
> > > Help! Is this a problem in DBI, DBD::ODBC, ODBC, or the
> > > MSSQL ODBC driver? Anyone got a work-round other than simply
> > > ignoring the error?
> >
> > Try using $dbh->do() and see if that works, rather than
> prepare() and
> > execute() separately.
>
> Since the error occurs in the FETCH('NUM_OF_FIELDS') and I can't do a
> FETCH('NUM_OF_FIELDS') if I don't have a statement handle. I
> don't really understand what you are asking.
>
> Over DBD::Proxy do() still fails. But that's not news since
> the DBD::Proxy do() is built out of prepare()/execute() and
> DBI::ProxyServer still calls FETCH('NUM_OF_FIELDS') on the
> underlying statement handle.
I would think that it's better for DBD::Proxy to map do() on the client to
do() on the server and let the server-side implementation do what it wants.
>
> Anyhow as requested...
>
> Running directly
[snip] looks like this ran fine to me
> ------------------------------------------
>
> So does this suggest that DBD::Proxy should implement do()
> directly rather than build it out of prepare()/execute()?
I would think so, as the semantics for do() imply that you are not expecting
results. Prepare()/execute() are expecting results. I should probably look
have DBD::ODBC handle NUM_OF_FIELDS better in those situations. Can you
send me a server side trace when you call from DBD::Proxy? Maybe there is
something simple I can do to make this easier on the user(s).
>
> Or should it make looking up NUM_OF_FIELDS a separate proxy
> transaction as required rather than do it earlier?
I would think that performance should dictate that...
>
> I've got some changes to do in DBD::Proxy anyhow so perhaps I
> should address this.
>
Let me know where it goes. I have a gut feeling that:
a) DBD::Proxy should probably map do() to do() directly
b) DBD::ODBC should probably handle prepare()/execute() on DDL
statements better -- but I suspect it's the ODBC layer giving the trouble
here as do() doesn't call the same sequence as
preare()/execute()/NUM_OF_FIEDS. I guess that most drivers return 0 for the
NUM_OF_FIELDS in this case???
Jeff
