Thank you all for your replies. I do understand the points you're making, i.e. it could be a security context problem in relation to what user account my COM/EXE is attached to, hence to what directories the EXE has the read/write privilege. If it is the case then my question is why Sqlite has no problem accessing the database file itself?
Eugene *********** REPLY SEPARATOR *********** On 01/06/2004 at 2:37 PM Lindsay Mathieson wrote: >Eugene Lin wrote: > >>Bert, >> >> >> >>>It is a COM-related problem, not a SQLITE problem >>> >>> >> >>I can now tell you that it IS a sqlite problem NOT a COM problem. Sqlite >is trying to create its temporary database at some location (which I'm not >sure where) and it failed. I have found that you can force sqlite to store >its temporary database in memory. Once I have done that, the problem has >gone! >> >> >Well my guess (from reading the previous emails) is that is neither a >COM or a SQLite problem - basically a lack of understanding re users, >services and nt securiity > >If your com server is running as a normal service (not interactive or >logged on) then it has no user profile. Which means it cannot access any >network directores etc, also it will have no user enviroment settings >such as temporary directories it can access. This why setting the temp >dir to memory works. > >The easy solutuin is to have the service logon as a user, either an >existing one or create a user account for it. > >Alternatively you could create a temp directory thats globaly >read/writable and have the service use that as its temp dir. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
