Fernando Dias wrote:

<<OSs may behave differently, but not users, no matter the country,
language, etc. >>

Too bad users don't have to take a test before they can be trusted with a computer...
Although then I suppose us programmer's would have to take a test as well.... I'd be in
trouble then!



<<There is only one detail that is not clear to me yet that is the best
location to the EDBConfig file. At the moment I'm using COMMON_APPDATA.>>


I am planning on keeping the config and catalog files in the same folder as the tables,
etc.  I know that Tim recommends that the catalog file be kept separate from the data
folder, but my reasoning for this is that if the user needs to move the database to a
different drive or computer, or if they need to send the database back to me for
troubleshooting, I can have them just move the entire contents of the folder.  

I want to avoid situations where:

A) The user might not move the entire database when moving to a new computer.

B) The user might end up (wrongly) creating several copies of the database files on their
computer, but if there is only 1 config file.... which folder does it belong too?

Does this make sense?

I am totally new to ElevateDB and also C/S databases and admit that I still don't have a
good understanding of the config/catalog files and the best practices in using them.


Dale






--
Fernando Dias
[Team Elevate]

Dale,

I would follow Tim's recommendation.

> I am planning on keeping the config and catalog files in the same folder as the tables,
> etc.  I know that Tim recommends that the catalog file be kept separate from the data
> folder,

I don't think Tim recommended that at all.
As far as I can remember (not much , what he recommended was to keep
catalog files in the same directory as table data files and the
configuration file elsewhere.

(Tim, please correct me if I'm wrong).

--
Fernando Dias
[Team Elevate]

> I don't think Tim recommended that at all.
> As far as I can remember (not much , what he recommended was to keep
> catalog files in the same directory as table data files and the
> configuration file elsewhere.
>
> (Tim, please correct me if I'm wrong).
>

Sorry, I went from memory and probably got it backwards.

I've read other posts about why the configuration file should be kept
separate from the data files but I still don't really understand the
ramifications of not doing so.

What kind of trouble will I get into if I keep them all together?

What advantages will I enjoy if I keep them separate?


Dale

PS: Thanks for your continued replies as this discussion is very helpful
to me.

Fernando,

<< I don't think Tim recommended that at all.  As far as I can remember (not
much , what he recommended was to keep catalog files in the same
directory as table data files and the configuration file elsewhere.

(Tim, please correct me if I'm wrong). >>

No, you're right.  In fact, it is impossible to keep the database catalog
separate from the table files.  They must always reside in the same database
path that is defined for the logical database in the configuration.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dale,

<< What kind of trouble will I get into if I keep them all together? >>

It's just very easy to accumulate multiple configuration files when copying
around databases if you keep the configuration file in the same directory as
a database.  Furthermore, if you want to blow away the database contents,
normally you can just erase the database directory completely.  However, if
you put the configuration file in there also, then you cannot do so without
destroying your configuration also.

<< What advantages will I enjoy if I keep them separate? >>

You'll avoid the above issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fernando,

<< Virtualization can be a problem, but not here, I think.
You can have virtualization problems if you hard-code the paths - then
Vista will map them to whatever it thinks is correct, but if you get the
locations by querying the OS using CSIDL_COMMON_APPDATA identifier at
runtime you will get the correct path in both operating systems. >>

You are correct.  The problem, as evidenced in the link that Hedley posted,
is installing something as an admin that creates a sub-folder in the
CSIDL_COMMON_APPDATA folder, and then trying to update the contents of that
folder when running as a non-admin.  This won't work in Vista without
modifying the user security of the created sub-folder so that all users can
have full control over it.

We've run into this with the ElevateDB Server, which keeps its edbsrvr.ini
file in the common app data folder.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> You are correct.  The problem, as evidenced in the link that Hedley posted,
> is installing something as an admin that creates a sub-folder in the
> CSIDL_COMMON_APPDATA folder, and then trying to update the contents of that
> folder when running as a non-admin.  This won't work in Vista without
> modifying the user security of the created sub-folder so that all users can
> have full control over it.

You are also correct
In fact I didn't pay much attention to the need to alter directory
permissions because it's very easy to set them (at least using
InnoSetup) and also it's not a Vista specific problem - I always need to
grant write permissions since the user can chose where to create the
database and it can be anywhere.

--
Fernando Dias
[Team Elevate]

>
> > You are correct.  The problem, as evidenced in the link that Hedley
> > posted,  is installing something as an admin that creates a
> > sub-folder in the  CSIDL_COMMON_APPDATA folder, and then trying to
> > update the contents of that  folder when running as a non-admin.
> > This won't work in Vista without  modifying the user security of
> > the created sub-folder so that all users can  have full control
> > over it.
>
> You are also correct
> In fact I didn't pay much attention to the need to alter directory
> permissions because it's very easy to set them (at least using
> InnoSetup) and also it's not a Vista specific problem - I always need
> to grant write permissions since the user can chose where to create
> the database and it can be anywhere.
>

I also use InnoSetup and set the required permissions during the
installtion.  I do not have the installer source to hand so will post a
follow up in the morning.

Stuart

>
> I also use InnoSetup and set the required permissions during the installation.  
> I do not have the installer source to hand so will post a follow up in the morning.
>
>

Here is the code I use with InnoSetup.  I set the permissions for ProductName directory
and have had no problems with Microsoft 2000, XP or Vista.
I've even done some initial testing on Windows 7 and it still works.

[Dirs]
Name: {commonappdata}\CompanyName; Flags: uninsneveruninstall
Name: {commonappdata}\CompanyName\ProductName; Flags: uninsneveruninstall; Permissions:
everyone-full users-full


Cheers Stuart

Stuart,

> [Dirs]
> Name: {commonappdata}\CompanyName; Flags: uninsneveruninstall
> Name: {commonappdata}\CompanyName\ProductName; Flags: uninsneveruninstall;
> Permissions:
> everyone-full users-full

In a C/S configuration it's EDB Server and not users that need to read/write
to the disk and the server normally runs under the SYSTEM account, so you
must set permissions to that account too. Also, you users don't usually nedd
full acess - you are giving regular users the power to alter permissions,
and that's not a good idea.
This is how I set permissions in the install script that installs the server
(I have 2 separate installs: one for the server and another for the
application):

[Dirs]
Name: "{commonappdata}\CompanyName"; Permissions: admins-full system-full
Name: "{code:GetDBRootPath}";  Permissions: admins-full system-full ; Flags:
uninsneveruninstall
Name: "{code:GetBKPath}";  Permissions: admins-full system-full users-modify
; Flags: uninsneveruninstall
Name: "{code:GetOutPath}";  Permissions: admins-full system-full
users-modify ; Flags: uninsneveruninstall
Name: "{code:GetInPath}";   Permissions: admins-full system-full
users-modify ; Flags: uninsneveruninstall

The first line creates and sets the permissions for the path where the
configuration file, migrator dlls and my own logs and other ini files will
reside.
The other lines are for the database and stores (backup and replication in
and out files), where "{code:Get ...}" are functions that return the paths
entered by the user.

--
Fernando Dias
[Team Elevate]