Slow Appends and Posts

[DORaymond]

Does anyone know if the issues surrounding slow appends and posts are addressed in V5. Also, would V5 be considered a client-server product?

[John Cunradi]

RE: Slow Appends and Posts

I'm not sure if this will help but I had some issues with slow appends and posts as well. My particular problem was because I used a "Mark:Delete Records" instead of a zap in a different operation. It caused the transaction table to grow and grow and grow with deleted records....just a thought.

[csda1]

RE: Slow Appends and Posts

Donald,


A5V5 is not "True Client Server". That does not mean it is slow though. See the thread "WAN/Virtual LAN possibilities?" where I discuss some of these issues.

Slow appends and posts are due to network issues (doubtful but possible) or methods you are using. Correct those, and you should see appends in 10 to 100 records per second range.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[DORaymond]

RE: Slow Appends and Posts

Ira,

Thanks for your reply. I too agree that Alpha in general is not slow (I have used it for 10 years, V4.5 for almost 2). The problem is that we have a fairly large app. (more than 20 tables, 70 forms, etc.) that we use to manage our entire manufacturing plant. It works beautifully except when we must use append or post operations (its tedious). I really need to remedy the lack of speed in that area.

We are running an up-to-date network with 100mps ethernet connections to a 2 gigabit backbone switch and a Pentium 4 server with Raid 5 drives and 1 gig memory. Perfomance with this network setup is not much better than our earlier 10mps setup.

The append and post operations are simple set to set operations that do append/post some variable also. There has been alot of talk about field rules, record locking, etc.that may have something to do with the speed problem. How is the append operation any different than a lookup where data is copied from one table to another? Lookups work instantly.

Any more ideas?

Regards,

Donald Raymond
Coastal Pipeline Products,Corp.
DORaymond#@cs.com

[csda1]

RE: Slow Appends and Posts

Donald,

Appends are no real different from doing lots of table reads followed by writes. Lookups to other databases are simpler since you already have the record open for change.

If you are violating a field rule during the append, or have some other complicated append/conditional replace expression, it may not be evaluating very quickly. There are many possible causes, but the best way to see the speed of an append is to append a table that you have exclusive control of (normally the case) to a table that is being used by one or more users or processes (This can be done simply by opening a form based on the table while doing the append). The reason for this is that while shared, A5 appends 1 at a time, updating indexes as it goes. The other way all records are appended and then all indexes are rebuilt (not what you normally want to do).

Your network seems fine, so it means there are probably some expressions used in the append operations that are less than optimal.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[Tom Cone Jr]

RE: Slow Appends and Posts

Donald,

might it be feasible to do any preprocessing and validation first, storing the results in temporary tables; and then using them to do the append? While total processing time might not be shorter, the user's perception might be more favorable.

Most of my experience has been on smaller apps. I usually process one table at a time. Have not tried set to set... I wonder if things might go faster if you did it one table at a time?

-- tom

[CraigSchumacker]

RE: Slow Appends and Posts

Donald:

Here's what I'd do if I were trying to isolate the issue.

1) Make a backup copy of the application on a local machine, at a time when it can be COMPLETELY copied - when no files are in use. On the local machine, disconnect from the server, set up a virtual drive to simulate your server, and COPY your backup onto the virtual drive. (All this may not be needed, but if you have any paths hard coded, then it is... You may also need to map a couple drives to the local computer)

Now, time an append, so you have a reference. At this point, you may be able to get an idea of what the network cost is on the append.

Replace the files on the virtual with the untouched copy on the local machine.

Now, see if at least part of the problem is within the field rules...

On the virtual copy, try removing all the field rules from the table that is being appended to. (To delete all field rules, edit the field rules and select RULES - Delete all rules from the menubar, then save the changes) Try your append now, timing it. If there is an improvement worthy of review, reinstall the untouched files to the virtual, and review your field rules. Look specifically at calculated field rules. Those that contain LOOKUP varients are prime suspects.

If the field rules are not the culprit, look into your indexes, as they may be taking a long time to rebuild...

I'd take Ira's advice and look into the appends themselves. Are there any filters there that may slow things down?

If sets are involved, I'd also look into the linking between tables... Not likely, but a possibility...

Hope this helps, and makes sense, but not necessarily in that order! This all may seem a bit tedious, but it will help to isolate where the blame lies.

Craig

[DORaymond]

RE: Slow Appends and Posts

Ira,

Yes, the appends I am using are involved,as I am actually appending one record from a table in a set to another table in the same set WHILE the set is open in form wiew. The append is only done with one record at a time (never more)and uses a filter. Each append takes about 5 seconds.

To be more clear, this section of the app. allows manufacturing supervisors to "pick" records out of a sales order table(items to be manufactured) and put them in a workorder table that reports to the shop floor. Both of the these tables (and a few others) are combined in a set. It would be easy to break the set down into smaller ones, but for reasons beyond explanation here, it would be nicer to keep them as configured.

I am sure that part of my problem is that I do not understand exactly what happens when the append operation takes place. Field rules are evaluated (by the way, can't I put an Ignore Field Rules statement in avoid them), filters are checked, indexes are updated, and records are locked. Is it documented somewhere what the sequence of events are.

Thanks for your help.

Donald Raymond
Coastal Pipeline Products, Corp.
[email protected]