I thought of another possible reason why this is going on. The code in
question works under one set of circumstances and not under another. If
there is no data in my database then I am able to save data. This begged
the question "why?" and the answer is because I do not load my data if I
start a new game. I have been looking at my lData code in my dataSystem
class and I found that I am getting errors there too when trying to close
my database connection from there. This, I think, is why I am getting
locked out during the save process. I am going to try updating the code in
lData and see what happens.
As for the fail path issue, it is not an issue or at least it has never
been for me. The way I understand it is that if you just put the file name
into a function requesting a path in Windows it will look in the folder the
process is running from for that file. Although you are right, I should be
a bit more explicit with the path, maybe use ./Databases/[filename] so that
it will explicitly look in the same folder and not have to use a default
behavior that can sometimes be fallible.
Thanks for the suggestions. Will post back what the results of my work
with lData are.
On Fri, Feb 21, 2014 at 3:59 PM, RSmith <rsm...@rsweb.co.za> wrote:
>
> On 2014/02/22 00:32, Geo Wil wrote:
>
>> 1. Windows 7 Ultimate 64-bit
>>
>> 2. Here is the path I am using:
>> void Database::openSave(bool* bErrors)
>> {
>> if (sqlite3_open("*scSave.sqlite*",&dBase) != SQLITE_OK)
>>
>> {
>> *bErrors = true;
>> createBInfo();
>> d.createBReport("SQL Code 1",sqlite3_errmsg(dBase),bLocale +
>> to_string(__LINE__),bTDate,"./SC_Log.txt");
>> }
>>
>> else
>> {
>> *bErrors = false;
>> }
>> }
>>
>> 3. I checked that earlier today as well as the permission on the database
>> itself. Everything checks out.
>>
>> 4. Here you inspired me to do some extra digging. I added some couts to
>> the player data transaction block in the event that error is not null and
>> I
>> got an error of "Database is Locked". This was surprising because I have
>> no programs open that have my save database open and the only other call
>> to
>> the database before the transaction block starts is the openSave function
>> listed above.
>>
>>
> That path doesn't seem like a path, but just a call to open a filename,
> which should be in the same folder as the exe. Now, depending on where the
> exe is in Win7, that could be a problem. If your exe is in any of the
> protected or system folders (such as Program_files), Windows won't let you
> edit files in those places, it might simply shift the file to the
> virtualized folder and open it there, which usually works ok and very much
> transparent to your app - unless you are trying to force the full path in
> an open statement, such as SQLite should be doing. This may explain why the
> permission seem ok but the physical file is locked when you try to open it.
>
> The way to fix this is to use the correct program data path (typically
> "c:\users\myUser\AppData\Roaming\MyProgramName\") or the user's documents
> folder (should you want this file to be handled by the user at some point),
> in stead of the exe path - and/or to let Windows know that you know what
> you are doing and expect your datafiles to be changed by specifying a
> manifest to your exe with appropriate settings - just MSDN "Manifest file"
> for examples.
>
> btw: Getting the path to the correct program data path on any PC requires
> simply a call to the Windows Shell API with the correct parameter, again
> just MSDN it.
>
> Good luck!
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
"I though what I'd do was, I'd pretend I was one of those Deaf-Mutes...Or
should I?" -- Laughing Man
______________________________
Laughing Man Productions² Entertainment and Gaming
Network<http://www.lmpgames.com>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
