Shared File Speeds

In trying to help someone troubleshoot a speed issue on a shared system, I’m not fining obvious reasons for frequent slowdowns. One moment everything seems to be working fine, but then it gets really sluggish on the simplest tasks.

For instance, clicking on a checkbox that has no connected procedure may be instantaneous, or it may take 30 seconds or more.

The database does have about 800 fields with the number shown set to 100, but the work is all in forms.

Even opening things like Server Administration or Settings (Preferences) become extremely slow and may sit with a beachball. Every client experiences the issue which doesn’t happen when the files are in single user mode.

Following these delays, the shared icon in the toolbar turns to a speech balloon when the delay ends, then moments later returns to the shared icon. (I can’t find what the balloon indicates.)

So I’m looking at the server.

Speed tests on the server show that the network connection is very fast. Activity Monitor on the server shows Panorama as the occasional primary power user but there’s nothing notable in it or any others. There are no Implicitly Triggered Procedures, etc.

With one connected user, the server log shows little activity other than keeping the record locked every 30 seconds.

The server is a Mini M2 running on Sonoma 14.5 with the latest Panorama and no other open applications.

Any ideas of what could be causing this stall?

That doesn’t sound like it has anything to do with it being a shared system. Certainly the Preferences window has absolutely nothing to do with any server - it doesn’t contact or access any server and in fact is not even aware of any server. The Server Administration window is of course aware of whatever servers you have configured but it isn’t really doing anything intense with them.

800 is a lot. I’ve never tried to share a database with that many fields. However, I would expect it to be a bit slower, but not beach balls for 30 seconds.

but the work is all in forms.

Complicated forms can cause slowdowns and beachballs, especially if you have multiple forms with view-as-list, text list or matrix. This has nothing to do with it being shared. See if closing all the forms solves the problem. If so, you can gradually add back to see what form or combination of forms causes the problem.

which doesn’t happen when the files are in single user mode

I’m kind of skeptical about this.

the shared icon in the toolbar turns to a speech balloon … I can’t find what the balloon indicates

The speech balloon means that the current record is locked.

So I’m looking at the server

I really think the symptoms sound like a client problem - in fact, I suspect that it has nothing to do with being shared.

There may be more to find, but as I dug through his files I found a lot use of:


The logs show that each time this is invoked there’s a Lock Record followed by a Commit Modified Data. On a huge form full of checkboxes, and every checkbox running this code it’s a wonder the server could respond at all.

I can now understand why it runs faster when not shared.

Still exploring…

Switching to graphics mode will definitely unlock the current record, which causes a commit. I think the lock record must have happened earlier. Actually, clicking a checkbox will lock the record (if the checkbox is associated with a database field).

In any case, yes, I :100: recommend that any instances of


should be removed.

This code was triggered by clicking on a checkbox??

Each Checkbox was set to call a procedure that ended with those lines.

And as I watched the logs, every time I clicked on a checkbox, both the lock and commit were logged.

That is exactly what should happen.

When any change is made to a record, the record is locked. Since clicking on a checkbox associated with a field causes the record to be locked.

Normally it would stay locked until you moved to a different record. So you could click on other checkboxes, edit fields, etc., without it locking.

But because of the code attached to each checkbox, it will lock and then immediately commit. Mystery solved.