DBStatement Execute() and Fetch() behavior...

[Dean Roddey]

OK. Well, that's a bummer, because that's going to require a good bit of magic behind the scenes to make that work. You can't destroy a connection object until you've cleaned up all of the statements that are open against it. Which, if you are just stopping the IDE and it has to clean up, it can't know these things.

So I guess I'm going to have to have the statement objects internally reference count their associated connection handles, so that it doesn't actually get destroyed until all the statements are destroyed that reference it, even if you destroy the connection object.

If I'd realized this, I probably wouldn't have even had a connection object and just let you connect via the statement objects and reference counted the connections behind the scenes. But, too late for that now. I guess I'll just document that the connection object is only required to create the statements and doesn't have to stay around necessarily once you've created any statements you want to create.

[jscheller]

It's always something... :-)

You could just document the order-of-destruction issue... It may be good practice just to use local statement objects anyway...

[Dean Roddey]

I think it's probably a good thing to use non-local statements. They may be fairly heavy to setup and tear down internally. So I think it should be supported. And since there's no good way to report the failure to clean up (because it happens in a destructor) and because even if it's reported the actual object doesn't get cleaned up, it's probably best I deal with it correctly. The same issue could occur in a driver when it's loaded and unloaded.

[Dean Roddey]

OK, I did the connection handle reference counting thing, so this shouldn't be a problem. You can either destroy or call Disconnect() on a connection object before destroying the statements and it won't cause a problem.