I am pre-setting up my server config file and have been using .\data
for the database location, is there any problem I should know about
when doing this? When the Server piece of our application is installed
the "data" folder is always a sub folder of where the server is.

Thanks Bern


--

Bern,

<< I am pre-setting up my server config file and have been using .\data for
the database location, is there any problem I should know about when doing
this? When the Server piece of our application is installed the "data"
folder is always a sub folder of where the server is. >>

As long as you don't have any server-side procedures or triggers that change
the current working directory, then you should be fine.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:10AFCB99-30E3-46CF-BC9E-2404AB770745@news.elevatesoft.com:

> As long as you don't have any server-side procedures or triggers that
> change the current working directory, then you should be fine.
>

This kind of thing usually works fine until you've forgotten about the
caveat, and then someone needs some more bells and whistles that make you
add some more functionality that breaks it.

When you release the code you spend weeks (well, maybe just hours) trying
to work out why it doesn't work anymore for one or two clients.

From bitter experience, I would suggest avoiding .\data like the plague,
and setting the path from the current path as in e.g.

ExtractFilePath(Application.Exename)+'Data'

By the way, IIUC Windows Vista will break this, as you are apparently not
allowed to write into the program directory but instead need to use one
of the data directories.

I get around this by using a function, so if ever it changes, it only
changes inside the function:

function MyDataDir:String;
begin
 Result := GetEnvironmentVariable('APPDATA')+'\';
end;

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

Chris,

<< This kind of thing usually works fine until you've forgotten about the
caveat, and then someone needs some more bells and whistles that make you
add some more functionality that breaks it.

When you release the code you spend weeks (well, maybe just hours) trying
to work out why it doesn't work anymore for one or two clients.

From bitter experience, I would suggest avoiding .\data like the plague,
and setting the path from the current path as in e.g.  >>

This is true.  I've been wanting to do a "best practices" section in the
manual, and the EDB manual may be the first to see it because it is
especially sensitive to relative path issues since the database paths are
stored.

--
Tim Young
Elevate Software
www.elevatesoft.com