>
>
> I've got a script I use for backing up MS-SQL databases via
> DBD::ODBC on Windows. It was working fine with ActivePerl
> 5.6.1 (build 633), DBI 1.30
> and DBD::ODBC 0.43, but when I upgraded to ActivePerl 5.8.4
> (build 810), DBI 1.42 and DBD::ODBC 1.09, it's not working
> correctly. What happens, is that the backup proceeds
> normally until just before it finishes. Then, the backup
> file (which I have watched grow during execution) is removed
> and the command finishes with no error indicated. I've
> tracked it down to a problem with SQLExecDirect, since I can
> get it to work by using a placeholder for the database name,
> which forces the normal prepare/execute rather than
> SQLExecDirect. I've reduced the problem down to a single
> $dbh->do. I'm attaching two versions: "good", which works
> because I used the placeholder, and "bad" which doesn't, as
> well as trace logs (with DBI_TRACE=9) for each of them.
I'm a little curious now. I notice that SQLExecuteDirect is returning -1, showing an
error. That's strange because I would have thought I would have attempted to parse the
error message, but it doesn't seem to be going there.
I have a few thoughts, after quick inspection:
#1, use prepare and execute without needing to bind parameters and you'll get
the
correct behaviour. (Ok, this falls under the category of "Doctor it hurts when I move
my
arm up ... So don't move your arm up :)
#2 It seems that the backup command returns a message and SQLExecute is still
trying to get row counts, etc, even though there were errors. That's why the "good"
log
looks different. The execute in either case returns SQL_ERROR, I'm guessing to flag
that
there are messages coming back, but none are coming back via SQLError. I'm surprised
at
that. It seems to be a difference between using SQLExecDirect vs that SQLExecute, as
you
saw.
What surprises me is that they behave differently on the server between the two (i.e.
one
deletes the file the other doesn't). From reading the SQL*Server docs, SQLExecDirect
uses
sp_executesql, which may behave differently, but works fine calling sp_executesql when
using prepare/execute.
I think it's a bug, but I don't believe it's in my control at this point.
Regards,
Jeff
