This process takes much longer than I expected. What does the system require in order to run more efficiently ?

I am running on a server, pentium 2, 233, 128 Meg.
My workstation is Windows 98, pentium 3, 766.

Any suggestions would be greatly appreciated.

Hello Sandra,

Do you mean that the import (and conversion) of a DOS specification is slower than you expected, or that the calculation of the resulting financial statement is slower? In either instance, I'd suggest moving the data local. You might also want to check whether you are running on a 10 Mbit or 100MBit network. If you think you are running on 100MBit (more common now), then you should make sure that your hub is a 100MBit hub, otherwise you're only running at 10MBit.

Other questions:

How large is your charge of accounts? How complicated are your financial statments? (number of rows & columns). Did your DOS spec round to the nearest $? This makes for a very complicated conversion, and you'll find the specification is simpler if you turn off rounding prior to conversion.

PS - Might be time to consider buying a new server - Pentium II/233 is pretty slow these days. What Network OS are you running? NT? Novell?

Q1) The import and conversion of the DOS specification was what was taking
the time. The calculation and recalculation times were acceptable.

Q2) I copied local and converted there - remarkable improvement(under 1
minute for most).

Q3) We are 10bit; Upgrading is not in our immediate plans.

Q4) Tried removing rounding on one of the killer specs and converted on the
server. It brought the conversion time down to 29 minutes with solid
packet. To be completely honest, I am not overly familiar with the DOS
specs so can't speak to the complexities but can tell you that 2 of the
reports never finished (I gave up) on my very own super fast machine. What
they have in common is that they list by department totalling by account or
category for actual, budget, and variance. They use little hats and tildes
to do their thing:

Example:

^^4140-400~4140-999

My plan at present is to use these as a learning tool, that is, I will
rewrite directly in the financial reporter to get a better understanding of
how it all works.

Sandra Zado,
Community Living Society

(Sandra had some problems getting this to post, so I've placed it here for others to follow the thread. - Andrew Bates)

Q1) OK. Presumably, that's a one-time "thing" (and in any event the task is fairly complete now).

Q2) It's not surprising you saw this improvement, especially given the answer to Q3. It's now the case, that local is significantly faster than "over the wire" (even with a 100MBit network), due mainly to the difference in "packet size" (the amount of information transfere in a block). Over the wire, this is unlikely to be bigger than 1024 bytes at a chunk. Your hard disk may deliver 8-16K at a chunk, and Windows goes out and grabs even bigger "chunks" and loads them into RAM). If you are creating reports from data that does not have to be "up to the second", you are always better off working with a copy of yesterday's data. (Part of Softrak's nightly backup is to create a copy of our database for reporting only.)

Q3) In your planing, you might make a note to consider this. It will probably make a bigger difference to your overall "perceived performance" than any other purchase. Also, you should not consider giving general high-speed access to the internet until you have made this upgrade. People downloading videos and music from the web will bring your local traffic to a halt. (Not that people do that you understand ).

Q4) OK - If you need the statements rounded, the financial reporter includes a function to round numbers. You'll need to "fiddle" to figure out how to deal with the rounding error.

OK?

PS. If you're willing, I would be interested in looking at the statements that wouldn't convert. I'd need a copy of your whole g/l database though.