The problem is that sqlite on Windows use the GetTempPath (win32 API).
This API is very problematic since it does not work from windows services and has security drawbacks as well (Writing to /tmp in unix can be problematic as well).
I had the same problem and had to change sqlite code.
I believe the right solution is to give the application the option to set the temporary files directory, then each application can solve it's problem easily and secure.
The solutions of changing the temp directory or the account are not always practical.


Thanks
   Avner

Steve O'Hara wrote:

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]






Reply via email to