Re: Number of users and performance

Jim Gordon sagely pontificated: > Your description suggests that your posting program is taking and > holding locks for long periods of time. That seems to be a problem with > the transaction design of the posting program rather than a performance > issue. Try redesigning it so that it doesn't, I'm guessing here but > it's a common mistake, do the whole or major parts of the posting run as > a single transaction. Alternatively only run the posting program when > nobody else uses the tables that it needs. This is a very common method > of avoiding otherwise unavoidable conflicts between the needs of the two > types of programs. And my earlier fatuous comment refers. Our experience with FourGen is that this kind of thing happens quite often, not with standard FourGen code (which is just slow from the CASE implementation), but because efficient coding within the FourGen paradigm is non-trivial. Please don't anybody take offence, because I include myself in this group (sort of). It *is* a difficult environment to adopt and make work well for you, which is why we generally handcode the performance critical routines into intermediate tables and then hand over to the FourGen routines (ugh, I know). Jim's point is very valid, but unfortunately it's not the only thing you have to look at. There are a bazillion other factors to consider which involve a *very* comprehensive understanding of how FourGen's internals masticate data. Good luck! -- Ciao, Billy +------------------------------------------------------------------------------+ | Billy Wheeler Junior Programmer / Director The West Solutions Group | +------------------------------------------------------------------------------+ | Oracle isn't the answer. Oracle is the question, and the answer is "no". | +------------------------------------------------------------------------------+