Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay.
This is why I asked if changing the file extenion to something other
than .mdb the OS won't recognize the file as a data file and leave it
alone.
Hhm.., Win10 perhaps? So annoying!
I use "app.dat" under the app folder in a subfolder named "UserData".
My installer sets up folder permissions during setup. So far this works
as expected!
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay. This
is why I asked if changing the file extenion to something other than
.mdb the OS won't recognize the file as a data file and leave it
alone.
I hate to keep beinbg a pain, but ..
What about the Windows [ ProgramData ] directory.
If the program\app is installed as an Administrator into the default directory then create and use the data files in the [ ProgramData ] directory. I can live with the program\app being installed anywhere I
just need to know that the correct data file is being updated and
where it's at.
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay.
This is why I asked if changing the file extenion to something other
than .mdb the OS won't recognize the file as a data file and leave it
alone.
I agree with Jim's reply! Note that I mention my installer *sets folder >permissions* for the target install folder (and its subfolders).
Tough call as to where you install to and where your app files are
stored but means you have to disburse your files. Things were nicer
when we could keep everything in one place, and so this is my
preference and is why my installer sets folder permissions. (Mostly
because they are portable -can be run from a memstik- and so do not use
the Registry to store settings. Makes things simple when everything is
in one folder!)
The installer also only replaces certain app files if they don't exist;
-its the app's job to manage user data files it creates!
On 12/6/2016 8:25 AM, HarryC wrote:
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay. This
is why I asked if changing the file extenion to something other than
.mdb the OS won't recognize the file as a data file and leave it
alone.
It has nothing to do with the file extension. Under Windows UAC (User
Account Control), your program simply doesn't have write access to files >under C:\Program Files or any other system location. But since so many
older programs assumed full access, UAC instead silently redirects such >writes to a virtualized store in the user's own directory.
https://www.symantec.com/connect/articles/folder-virtualization-concepts-windows-vista
You can't control this on behalf of your users, it's all down to their
own UAC settings and Windows itself. Better you should learn and follow
the rules, and avoid all this.
Hhm.., Win10 perhaps? So annoying!
I use "app.dat" under the app folder in a subfolder named "UserData".
My installer sets up folder permissions during setup. So far this works
as expected!
In additioon to Jim's counsel.., the user profile 'AppData' folder
allows modifypermission for thee user. Also, in the event of more than
1 user on the maxhine, work with the 'default' user's AppData folder so
all users edit the same data file.
Ok - Once again thanks guys
On Tue, 06 Dec 2016 23:49:38 -0500, GS <gs@v.invalid> wrote:
In additioon to Jim's counsel.., the user profile 'AppData' folder
allows modifypermission for thee user. Also, in the event of more than
1 user on the maxhine, work with the 'default' user's AppData folder so
all users edit the same data file.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 87:49:40 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,252 |