Eugene, Not to state the blindingly obvious but..... The COM/EXE will probably have read/modify access but not write?
To be honest Eugene, you've got to do some leg work yourself here - read a bit of background about COM/EXE and DCOMCNFG. This thread is starting to get off topic. The default security identity for COM/EXEs is the launching user which in the case of IIS is SYSTEM. This is notoriously crippled when writing files. Steve > -----Original Message----- > From: Eugene Lin [mailto:[EMAIL PROTECTED] > Sent: 07 January 2004 01:03 > To: Lindsay Mathieson; SQLite Users > Subject: Re: [sqlite] Sqlite & COM/EXE server > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
