ADO inside win32 services goes boom
-
Hi everyone, I've wondered across a peculiar issue with ADO (although something else could be the culprit, but through my investigation, I believe it to be ADO). I have written a service that uses ADO. When running the service as a console app, everything works great. However, when the service is run 'as a service' in the SCM, I find a problem with the connection. Basically, this is what I've found to happen: 1. I issue a connect() call, and it returns S_OK. 2. Immediately after that, I execute a simple query, say "select count(*) from table1". At this point, when running as a normal app, the query executes and all is well. However, as a service, the query fails. Upon further inspection, doing a check on whether the connection is actually "connected", I find that it is infact disconnected. Any ideas? I've been thrashing my brains with this problem for a few hours now. Maybe someone can shed some light on this? I have tried changing the account under which the service runs. That didn't work. I tried testing different data providers. Same problem. Anything else I can try? Thanks, Peter
controlSHIFT [Glossary Manager] [AfterThought Backup Lite] All good things were meant to be improved
-
Hi everyone, I've wondered across a peculiar issue with ADO (although something else could be the culprit, but through my investigation, I believe it to be ADO). I have written a service that uses ADO. When running the service as a console app, everything works great. However, when the service is run 'as a service' in the SCM, I find a problem with the connection. Basically, this is what I've found to happen: 1. I issue a connect() call, and it returns S_OK. 2. Immediately after that, I execute a simple query, say "select count(*) from table1". At this point, when running as a normal app, the query executes and all is well. However, as a service, the query fails. Upon further inspection, doing a check on whether the connection is actually "connected", I find that it is infact disconnected. Any ideas? I've been thrashing my brains with this problem for a few hours now. Maybe someone can shed some light on this? I have tried changing the account under which the service runs. That didn't work. I tried testing different data providers. Same problem. Anything else I can try? Thanks, Peter
controlSHIFT [Glossary Manager] [AfterThought Backup Lite] All good things were meant to be improved
Peter Mares wrote: I have tried changing the account under which the service runs. That didn't work. hmmm...... That was my first thought. I have written a few services that update different data sources (dB2, MS SQL, Access) with ADO and ADO.net and not had this issue. Just as an idea, is it possible that you are catching an exception somewhere in your code that is not getting propigated back to the caller? Hey don't worry, I can handle it. I took something. I can see things no one else can see. Why are you dressed like that? - Jack Burton
-
Peter Mares wrote: I have tried changing the account under which the service runs. That didn't work. hmmm...... That was my first thought. I have written a few services that update different data sources (dB2, MS SQL, Access) with ADO and ADO.net and not had this issue. Just as an idea, is it possible that you are catching an exception somewhere in your code that is not getting propigated back to the caller? Hey don't worry, I can handle it. I took something. I can see things no one else can see. Why are you dressed like that? - Jack Burton
Hey, thanks for the reply. I found the problem. When running under the SCM as a service, the SCM obviously takes the "entry point" nominated in the dispatch table that is passed into StartServiceCtrlDispatcher( ) and puts it into another thread. Since I was calling CoInitialize BEFORE this, COM never got initialized, or so it seemed. Simply putting CoInitialize into the entry point function sorted me out. As an aside, I am slightly curious why, before the fix, calls the ADO Connection::Open( ) function SUCCEEDED and the CreateInstance( ) function returned what seems to be a valid interface pointer to the Connection object - weird. Anyhow, atleast its sorted out :D Thanks, Peter
controlSHIFT [Glossary Manager] [AfterThought Backup Lite] All good things were meant to be improved