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:(which I'm not
Bert,is trying to create its temporary database at some location
It is a COM-related problem, not a SQLITE problemI can now tell you that it IS a sqlite problem NOT a COM problem. Sqlite
sure where) and it failed. I have found that you can forcesqlite 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]