Can A2k run over a 1.5mb line (1 Viewer)

[stormin_norm]

Can A2k run over a 1.5Mb line? Would A2002/2003 run better?
Any network parameters to tweak for speed? Any registry settings for Access worth trying?

Splitting it to a fe/be did nothing for performance. It actually ran slower

I read other threads and will try to turn off name auto-correct and see if the IT group can move it up the directory tree. But is \\serverX\department\Local\apps\admissions\ "REALLY" that big of a performance penalty?

background:

At my clients campus network they have a remote site connected with a 1.5Mb connection. When I access an A97 db it is slow, but functional. When in Task manager it always showed A97 running, never 'not responding'

I ran an A2k db, it is extremely SLOW and typically can not edit forms without watching task manager sit in a 'not responding' status for 30 seconds- several minutes. This is causing corruption because we need to kill the process.

I split the db to a fe on a local pc and be on the server and it ran SLOWER than an 'unsplit' db running on the server! 6 minutes to load a form! So there goes the fe/be theory.

 

[The_Doc_Man]

Can A2k run over a 1.5Mb line?

Yes. Ac2K is way too STUPID to know the difference between fast and slow lines. It just uses Windows File Sharing service, trusting IT to "do the right thing" when it needs to. (As if anyone should trust a Bill Gates product...)

Would A2002/2003 run better?

Doubt it. They aren't bright enough to know better, either. Same Win File Share services, same level of trust.

But is \\serverX\department\Local\apps\admissions\ "REALLY" that big of a performance penalty?

Could be. In this case, I would suggest that the problem isn't the .MDB, but rather is the .LDB file, which ALWAYS resides in the same folder as the .MDB, and THERE is where you have to do a bunch of file-search actions. The .MDB BE file is probably not being opened and closed a lot, but the lock file is being opened and closed to a fare-thee-well.

Further, every time you traverse that path, you MUST re-evaluate the permissions for EVERY STEP ALONG THE WAY - because among other detailed permissions you must verify, there is "Traverse Folder." If you share this folder among many groups, the security list on each folder can get very bloated very fast. If you bring the folder up a couple of levels, TWO advantages apply.

First, instead of four folders in the path and four sets of Access Control Lists to evaluate each time, you have fewer folders and fewer ACLs to evaluate. At the top level (i.e. \\server\device\top\x.MDB), you have the device permissions and the \top folder permissions and that's it.

Second, the higher the level of the folder, the less likely that you will have so many users sharing the path, which means SMALLER ACLs, which are also faster to evaluate against your user's security token list.

This is causing corruption because we need to kill the process.

If you can't afford to let the process finish, you can't afford to start it in the first place.

On second reading, that last comment sounds brutal, but it wasn't meant to be that way. I won't mince words for you. That is my opinion.

The cost of doing business over a slow link is that you must be willing to wait for it to take that long. If you are not willing, you should not be doing that type of business.

Now, it might be possible to redesign the db, but I'm not going to advise that. I doubt you can do enough to make a slow line look like a speed demon. Access is just too bulky/balky to allow that.

On the other hand, there IS another possibility, but it costs money. If you don't have the money, you're still stuck - but here's the thought anyway, in case you happen to have this on-site already and could piggy-back your usage on your existing licenses.

Some forum members have tried running Citrix servers so that the application is running ENTIRELY on the remote host machine and only the Citrix links run over the slower line. The thing that kills you on a slow line is the Access data exchange, where queries (and embedded queries) have to read the entire table across the link in order to form the list of selected records. (Why else would they call it a SELECT statement, eh?) By making the exchange purely local, you minimize the data transfer load on your slow line.

 

[stormin_norm]

Thanks DOCman!
I've asked them to move the database up in structure. Not physical structure, but logical structure. I'm not sure if that will help or not in the Novell world. There is a Novell kb article confirming too many subdirs is bad.

Good point about the ldb file. It makes sense why the fe on the local pc was choking. I pointed to a local ldb file also.

...If you can't afford to let the process finish, you can't afford to start it in the first place...

True, true. You have to pay to play. They have run MS Terminal Services at another remote location. So we may set that up for here. I'll check if they have a citrix license also.

 

[stormin_norm]

...I would suggest that the problem isn't the .MDB, but rather is the .LDB file, which ALWAYS resides in the same folder as the .MDB, and THERE is where you have to do a bunch of file-search actions. The .MDB BE file is probably not being opened and closed a lot, but the lock file is being opened and closed to a fare-thee-well.

What about the security .mdw & .ldb? Does it matter if they are local or remote? There should not be a lot of updating or reading going on with the security lock file. Simply write operation when the db opens & delete entry when it closes. Correct?

 

[The_Doc_Man]

Simply write operation when the db opens & delete entry when it closes. Correct?

Possibly NOT correct. Record locking is stored in the .ldb file, too. Every update through a form/query/directly-opened-table involves SOME degree of data locking unless you have turned off locks on EVERYTHING (not a good idea...).

Think "Karate Kid" ---- Lock on, lock off. Lock on, lock off. With appropriate hand-waving. And this is at the RECORD level if you are doing updates or have reports that do even minimal locking.

Now, the .mdw stuff isn't used THAT often and isn't that big when it is used. So there, I might agree that such load is minimal.

 

[stormin_norm]

I like that fancy hand waving Doc Man!

There are two .ldb's, ex: db1.ldb (database) and users.ldb (security). So I have to assume the karate kid is happening in the db1.ldb vs. the security lock file. The db1.ldb will always be in directory of the mdb (db1.mdb), Therefore on the server. And the users.ldb could be either on the server or on the local hard drive depending which security file I use.

I did find some additional threads on novell kb. The performance issues are short directory path (your acl example), OpLock and Client File Caching