> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e@gmx.net]
> Sent: 17 May 2000 17:18
> To: Dave Page
> Cc: 'pgsql-hackers@postgresql.org'
> Subject: Re: [HACKERS] ODBC & v7.0(Rel) Errors with Users and
> Databases
>
>
> Dave Page writes:
>
> > ERROR: DROP DATABASE: May not be called in a transaction block
>
> This command can't be rolled back so you aren't allowed to
> try. This was
> thought as an improvement. In general, a database isn't a
> database object
> so one shouldn't be transacting around with them. (Same goes
> for users.)
This makes perfect sense of course.
> > The ODBC log (and knowledge that it isn't pgAdmin or M$
> ADO) shows that the
> > ODBC driver is automatically wrapping the query in a transaction.
>
> I don't know anything about ODBC but it certainly should
> provide a means
> to execute a command without that wrapping block. Is this a special
> function or do you just execute some exec("DROP DATABASE") style call?
Yes, I just issue the DROP DATABASE sql exactly as I would issue and INSERT,
DELETE or UPDATE query. From my fumblings around in the source for the ODBC
driver I have found what I believe to be the offending code in statement.c
at line 748 in the version shipped with 7.0, however I know nothing about
how the driver works and my C is far from good so (having very little spare
time also) I'm reluctant to try to fix it myself:
/* Begin a transaction if one is not already in progress *//* The reason is because we can't use declare/fetch
cursors
without starting a transaction first.*/if ( ! self->internal && ! CC_is_in_trans(conn) &&
(globals.use_declarefetch || STMT_UPDATE(self))) {
mylog(" about to begin a transaction on statement = %u\n",
self); res = CC_send_query(conn, "BEGIN", NULL);
Again, any assistance would be greatfully received!
Regards,
Dave.
--
"If you stand still, sooner or later something will eat you." - James Burke
http://www.vale-housing.co.uk/ (Work)
http://www.pgadmin.freeserve.co.uk/ (Home of pgAdmin)
