[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Client-server strategy for simulating a server-side join is not working (sports 2000)

  • Thread starter Thread starter dbeavon
  • Start date Start date
Status
Not open for further replies.
D

dbeavon

Guest
Patrick, thanks for your tip about getting all customers. I'm always happy to hear from other OE customers who are using ABL over a client-server connection. I'd guess that over half of OE developers are still using "shared memory", and it is hard for them to appreciate the additional challenges involved in running ABL on a remote tier, like from load-balanced PASOE servers. Improving the performance of client-server joins is not an old topic; here are some links to various explanations that explain why client-server behaves poorly compared to a similar "shared memory" program: knowledgebase.progress.com/.../000053086 knowledgebase.progress.com/.../18342 knowledgebase.progress.com/.../000012195 community.progress.com/.../add_server-side_joins__better_networking_performance I would certainly get *all* table records whenever dealing with moderately sized tables, but in our environment the customers list and products list grow very large. I would rather get the orders in a date range (or the active ones) and then go after the customers and products in a secondary step. When getting customers and products, it is likely that I would only need less than 1,000 of them (as identitified by the foreign keys on the orders), and this would be under 1% of the total customers/products in the database. That is why I was playing with QUERY-PREPARE as a workaround, but the strategy wasn't very successful. The purpose of using the dynamic query was self-defeating since the *compilation* of the query did all the same round-trips that I was hoping to avoid in the first place! Personally I think it is a bug that the compilation of my dynamic query would need to repeatedly fetch the "CustNum" schema hundreds of times in a loop. This seems to be the case even if you use -cache. The compilation ends up taking at least 50-100 ms by itself, and that is before we even begin to fetch the customers. I will open a support case. I think the behavior of QUERY-PREPARE needs some explanation, in the very least.

Continue reading...
 
Status
Not open for further replies.
Back
Top