EDBConfig.EDBCfg  must to same ( Z:\MYPROG\EDB )  for all PC

or must to be in personal user dir ( C:\USER\NAME\...\TEMP )   ?

Mauro


I think you are unfortunately confusing yourself. You have two cases:

1. the application is installed on a network
2. the application is installed on a standalone pc

When you install on a network there are two ways to go about it:

a. put a single copy of the application onto the server
b. put a copy of the application onto every pc that uses it on the network.

From your posts it looks as though you go for option a. Essentially the shortcut icon holds the executables path. If you go for option b you need to supply a file yourself saying where the executable is.

The final bit is where you put the data

i) in the same directory as the application executable
ii) in a subdirectory off the directory holding the executable or in a subdirectory whose path can be determined from the executables directory
iii) in one of the windows predefined directories (eg ProgramData under Vista), or a subdirectory of it
iv) at some totally random place

Only with option iv) do you have a problem. Then you need to supply some information to the .exe to say where the data is (eg a .ini or a .txt holding the path)

Otherwise when you open your executable (and it doesn't matter wether its local or networked) get the executables path, work out from that where the data will be, check if that path is already where the database says it is and if not alter the database accordingly.


Roy Lambert [Team Elevate]

Mauro


As they say in Highlander - THERE CAN BE ONLY ONE - one configuration file that is.

Here's what I'm doing

procedure Tdm.DataModuleCreate(Sender: TObject);
var
sl: TStringList;
Here: string;
begin
TfREngine.Active := False;
Here := IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0)));
if FileExists(Here + 'TfR.ini') then begin
 sl := TStringList.Create;
 sl.LoadFromFile(Here + 'TfR.ini');
 Here := sl[0];
 sl.Free;
end;
TfREngine.ConfigPath := Here;
TfREngine.TempTablesPath := GetWindowsTempPath;
TfRSession.LocalConfigPath := Here;
TfRSession.LocalTempTablesPath := GetWindowsTempPath;
end;

The datamodule is the first thing created in the project and I'm either going to keep the config with the exe or somewhere else. If somewhere else I simply tell it where.

Roy Lambert [Team Elevate]

> When you install on a network there are two ways to go about it:

> a. put a single copy of the application onto the server

YES

> ii) in a subdirectory off the directory holding the executable or in a
> subdirectory whose path can be determined from the executables directory
YES

> Otherwise when you open your executable (and it doesn't matter wether its
> local or networked) get the executables path, work out from that where the
> data will be, check if that path is already where the database says it is
> and if not alter the database accordingly.

this is the problem.

Yes my situation is similar you think:

I have one user that run my program from c:\myprog\myexe.exe (the server
pc),
Another run my program on the network from z:\myprog\myexe.exe ( z: is the
c:\ of the server shared!!)
Another run my program on the network from p:\myprog\myexe.exe ( p: is the
c:\ of the server shared!!).

The last two users are in the same condition but one have mapped the shared
unit of the server with Z and the other one with P.

Now everybody knows, from the icon, the executable path but they are 3
different path:

C:\myprog
Z:\myprog
P:\myprog

If one user runs a query to change the path of the database (  ALTER
DATABASE myDB PATH ''' + C:\myprog + '''');    ) this path changes for
everybody !

And the other two users cannot access the data..
The client pc just have the program's icon on the desktop; just the link to
the EXE..
This situation is very confortable to support and I would to maintain this.
I would not use other file or other setup on the client pc.
I have thinked to use a UNC path for my database but I this doesn't work in
a standalone installation: just one pc without client, without shared disk.
I would find  the same solution for standalone and network installation if
possible..

Mauro,

<< I have thinked to use a UNC path for my database but I this doesn't work
in a standalone installation: just one pc without client, without shared
disk. I would find  the same solution for standalone and network
installation if   possible.. >>

You really can't.  You'll have to know whether the target drive is a network
drive or not, and act accordingly.  Here is some appropriate code from Peter
Below:

http://groups.google.com/group/borland.public.delphi.winapi/browse_thread/thread/e7e06af51edf3214/93a169b1ebf452d6?lnk=st&q=delphi+detect+network+drive#93a169b1ebf452d6

--
Tim Young
Elevate Software
www.elevatesoft.com

Mauro


OK this is somewhat different to my original understanding. As far as I can see you're trying to operate ElevateDB in the same way as DBISAM and you can't. The transition is painful (I know I've been there) but you have to adjust your thinking to the new way of doing things.

With DBISAM you could just give a table a path and it worked with ElevateDB you can't.

There are two pieces of information your application needs 1. the path to the config files and 2. the path to the database. With the way you're doing things eg each PC on the network having a different mapping then the best I can suggest is that you have a .ini file in the same directory as the application .exe which gives the path to the config files in UNC format. Use this to set up your app. Set up the database path in UNC format and at the cost of one small extra text file on the server you'll have a working system that to the users will appear the same as now.

The standalone system is just that a standalone system. Set it up accordingly (you can still use an ini file but its contents will be local rather than UNC). Stop trying to squeeze everything onto the same path. You won't succeed, also if its being installed at a location where you don't have control over the hardware you have to allow for the users to install the app and database where they want.

Roy Lambert [Team Elevate]

Roy,

<<I have no idea what the c$ is in \\NAMEPC\c$\MYPROG

C$ is a hidden share used in Windows NT/2000/XP/2003 networks for the
administration of workstations and member servers. Hidden shares can
also be created by users for their own purposes.

--
Regards,
Jan Ferguson [Team Elevate]


Roy Lambert wrote:

<<Mauro
<<
<<I have no idea what the c$ is in \\NAMEPC\c$\MYPROG

Roy Lambert wrote:

> Mauro
>
<snip>
> OK this is somewhat different to my original understanding. As far as
>
> There are two pieces of information your application needs 1. the
> path to the config files and 2. the path to the database. With the
> way you're doing things eg each PC on the network having a different
> mapping then the best I can suggest is that you have a .ini file in
> the same directory as the application .exe which gives the path to
> the config files in UNC format. Use this to set up your app. Set up
> the database path in UNC format and at the cost of one small extra
> text file on the server you'll have a working system that to the
> users will appear the same as now.
>

from a non-EDB user - still stuck on DBISAM ...

I have avoided the use of .INI files as well and choose to use command
line parameters in the program shotcut.

e.g.
Peer to peer (fileserver) example:-

....PathToMyEXE\MyApp.exe -c P2P -p "C:\MyApp\Data"

Client/Server example:-

....PathToMyEXE\MyApp.exe -c C/S -s ASL3

Now the shortcut is unique to the client machine, but the app couldn't
care less whether it is UNC, mapped drives or pointing at a server - it
can always find and open the database and the only code I have to do is
for the minor differences between fileserver and client/server.

Other things like individual preferences that I would be tempted to put
in a .INI file are put in a Config table that has as part of its
primary key the computer name and username.  The Config table gets
backed up with the rest of the data, so to recover a client machine all
I have to do is recreate the shortcut.

Cheers

Jeff


--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
Joan and Jeff Cook
The Cooks Oasis
www.cookislandsoasis.com

Jan


Oh

Roy Lambert

Jeff


Neat idea. I've always tended to avoid that so any users (aka computer morons) who set up their own shortcut don't have to worry.

Roy Lambert