I have a customer who is having an unusual problem with my app (Delphi 7
and DBISam 3.24).  The data files are in a shared folder on their
network.  When the first user starts the app, they get in fine.  When a
second user start the app, it appears to hang until the first user exits
the program.  (The program is installed locally on each workstation.)
Both users have Modify, Read, and Write privileges on the data folder
(as evidenced by the ability to run the application).

The program works fine for other multi-user customers, so I'm not sure
what might be different about the environment at this particular site.
The data files are on a Win 2003 server, and the workstations are
running XP Pro.  (I assume all service packs are in place, but I forgot
to ask.)  UseOpportunisticLocking and EnableOpLocks in the Registry are
set to zero.

It would be one thing if the program did not run on the second
workstation, but I can't imagine what would cause it to wait until the
first instance closes before opening the data files.  (I am assuming
this is the point at which the application hangs as the program is
starting and then hanging.)  Other than accessing the same database
files, there is no communication between the two instances.

So what else can I have the user try to figure out why only one instance
of the application can run at the same time?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< I have a customer who is having an unusual problem with my app (Delphi 7
and DBISam 3.24).  The data files are in a shared folder on their network.
When the first user starts the app, they get in fine.  When a second user
start the app, it appears to hang until the first user exits the program.
(The program is installed locally on each workstation.) Both users have
Modify, Read, and Write privileges on the data folder (as evidenced by the
ability to run the application). >>

Does it matter which user starts first ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> Does it matter which user starts first ?

Not from the user's report.  There are several workstations displaying
the same behavior.  I will double-check this with them.

I added debugging code (CodeSite by Raize Software) and if the log file
generated by CodeSite can be trusted to be complete (the user has to
kill the task) the second copy hangs part way through opening the list
of tables.  (A CodeSite message just before the "Open" logs some of the
table open commands, but not all of them.)  The last table mentioned in
the log is a non-critical table, so I am going to have them delete it
and let the app re-create it to see if this resolves the problem.

However, any other suggestions of things to look at are more than welcome.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Tim Young [Elevate Software] wrote:
>
> Does it matter which user starts first ?

Follow-up from the customer...

They have 3 different workstations running the program.  It does not
matter which starts first or second, the second workstation starting the
app always hangs.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon Turner wrote:
>
> I added debugging code (CodeSite by Raize Software) and if the log file
> generated by CodeSite can be trusted to be complete (the user has to
> kill the task) the second copy hangs part way through opening the list
> of tables.  (A CodeSite message just before the "Open" logs some of the
> table open commands, but not all of them.)  The last table mentioned in
> the log is a non-critical table, so I am going to have them delete it
> and let the app re-create it to see if this resolves the problem.

Follow-up...  The customer deleted the table that was the last one
referenced in the CodeSite log.  Starting the program on the first
workstation re-creates the missing file.  Starting the program on the
second workstation creates a new log file that progressed through a
couple more tables before hanging.

(I'm not sure whether the program actually got farther, or whether
previously buffered messages actually got written to the log file before
the program was killed.  I'm not familiar enough with the inner workings
of CodeSite to know for sure which.  In the Delphi IDE the messages get
written immediately to the log.)

I'm going to have the customer delete all of the existing tables and
have the app create a new set to see if this helps.

Again, any suggestions/ideas on what's happening or why are more than
welcome.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

"Gordon Turner" <gordon@mycroftcomputing.com> wrote in message
news:F5FA8348-8F4C-4D9A-BDE5-776277326FBD@news.elevatesoft.com...
>
> I'm going to have the customer delete all of the existing tables and have
> the app create a new set to see if this helps.
>

Fine, then have the user exit the program, then reload it and open the
tables normally. It might have something to do with the fact that another
program has just created the file and is still running, so you can't get
access to the file until the app that created it exits.

Robert

Robert wrote:
>
> Fine, then have the user exit the program, then reload it and open the
> tables normally. It might have something to do with the fact that another
> program has just created the file and is still running, so you can't get
> access to the file until the app that created it exits.

The program automatically creates its own data files if they are missing
(table by table) before it attempts to open any of them.  The user has
no control over how the tables are opened, and they are always opened
non-exclusively until other possible user interactions take place.

But in this case, all the customer is trying to do is start the program
from two different workstations - just open the thing and not perform
any other actions.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon Turner wrote:

> Tim Young [Elevate Software] wrote:
>
>>
>> Does it matter which user starts first ?
>
>
> Follow-up from the customer...
>
> They have 3 different workstations running the program.  It does not
> matter which starts first or second, the second workstation starting the
> app always hangs.
>

Is there any way to determine if this is a locking problem? Does DBISAM
have a list of active processes which may tell you what a process is
waiting for? (Like MySQL's "show processlist")

You could run FileMon for *.DAT;*.IDX;*.BLB files to see what the last
files opened were just before it hung.

See http://www.microsoft.com/technet/sysinternals/FileAndDisk/Filemon.mspx

Sam

Gordon,

<< The program automatically creates its own data files if they are missing
(table by table) before it attempts to open any of them.  The user has no
control over how the tables are opened, and they are always opened
non-exclusively until other possible user interactions take place. >>

Yes, but there will be issues if you try to open concurrent clients at the
same time when the tables don't exist yet and you're just creating them.
Creation of the table requires exclusive access and this will conflict with
any shared table open.  However, you should be getting an error on one of
the clients at some point.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> Yes, but there will be issues if you try to open concurrent clients at the
> same time when the tables don't exist yet and you're just creating them.
> Creation of the table requires exclusive access and this will conflict with
> any shared table open.  However, you should be getting an error on one of
> the clients at some point.

I would expect an error/exception in that case as well, not an
application just hanging.  (Note that by the time the main screen is
displayed, the tables have been created, and I display a progress bar as
they are being created so the user knows this is happening.)

I'm using EurekaLog as well, so if I'm not displaying some kind of
message when a problem occurs, I would expect that some kind of
exception screen would be displayed - even the standard Delphi message
that gets displayed for unhandled exceptions.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com