Board index » delphi » LCK and NET files - InstallShield running from CD

LCK and NET files - InstallShield running from CD

We have an issue we seem unable to resolve. I would appreciatte any
insights.
We have a small EXE we run at the end of doing an InstallShield
Setup.exe
program that fails due to the LCK and NET files Paradox tries to create.
It fails at the first attempt to do anything in Paradox that might
create
a Lock. In this case it is a line to CREATETABLE.

The InstallShield Setup.exe does its job uncompressing and distributing
database tables and new EXEs, then we have this EXE that moves data and
makes chamges to the existing data, and basically upgrades our users
from
version 1.5.2 to version 1.6.1. Since the CD is read only as soon as
there
is an attempt to create an LCK or NET file the EXE gets an exception and
quits. The InstallShield IWZ has the following:

     <INSTALLDIR>/OneSixOneUpdate.exe

as the call to our update EXE. To me this says, "Please go run this EXE
from the hard disk where the install is being done." This seems to me
that this would solve the problem, but no. After the failure we go look
at the files and sure enough InstallShield did its job distributing all
the necessary files, one of them OneSixOneUpdate.EXE. So we run it and
it works just fine. The upgrade works great, just as tested (1000 times)

What is not clear is why an attempt is made to create the LCK files on
the
CD when we seem to be running the EXE from the hard disk not the CD.
Andrew
believes it is because the parent is InstallShield's Setup.exe so it
gets
Paradox's LCK files. This makes sense to me. When we do the install
program
from an un0write-protected Zip disk you can see the LCK files being
created on it, and sure enough it runs to completion.

How do we resolve this. I am sure we are not the first people to
encounter
Paradox lock files using InstallShield. Thanks for any help.

Jeannine Menger
PC Synergy
760-931-0350 x199

 

Re:LCK and NET files - InstallShield running from CD


Quote
>What is not clear is why an attempt is made to create the LCK files on
>the
>CD when we seem to be running the EXE from the hard disk not the CD.
>Andrew
>believes it is because the parent is InstallShield's Setup.exe so it
>gets

My guess is that the way InstallShiled starts the .exe the startup directory is
on the CD drive.  Delphi defaults its PrivateDir to the startup directory.
If this is the case the solution is to set the session.privateDir property to
something on the hard drive(Probably the Windows Temp directory) before you
program accesses any tables.

--
Brian Bushay (TeamB)
Bbus...@NMPLS.com

Re:LCK and NET files - InstallShield running from CD


In addition to Brian's comments, if you want to use the installation
directory as the private directory for your program you could change the
command in InstallShield to

<INSTALLDIR>/OneSixOneUpdate.exe <INSTALLDIR>

This will pass the installation directory as a command line parameter to
your program. You can then use it to set the private directory.

Session.PrivateDir := ParamStr(1);

Bill

--

Bill Todd - TeamB
(TeamB cannot respond to questions received via email)

Re:LCK and NET files - InstallShield running from CD


Quote
Brian Bushay TeamB wrote:

> >What is not clear is why an attempt is made to create the LCK files on
> >the
> >CD when we seem to be running the EXE from the hard disk not the CD.
> >Andrew
> >believes it is because the parent is InstallShield's Setup.exe so it
> >gets

> My guess is that the way InstallShiled starts the .exe the startup directory is
> on the CD drive.  Delphi defaults its PrivateDir to the startup directory.
> If this is the case the solution is to set the session.privateDir property to
> something on the hard drive(Probably the Windows Temp directory) before you
> program accesses any tables.

> --
> Brian Bushay (TeamB)
> Bbus...@NMPLS.com

Gentlemen,
I thank you once again for your timely responses. What you say makes
PERFECT sense (both of you).
I will try this Tuesday and post if there are any problems. I suspect
there will
not be.

Jeannine Menger
PC Synergy
760-931-0350 x119

Other Threads