D
dbeavon
Guest
Just to be clear, the simulation of a server-side join that I provided above is intended to produce the same results as the program below. I would obviously prefer to write my code this way, but server-side joins are not yet available for ABL code connecting against the OE database. FOR EACH Order WHERE Order.OrderDate >= 01/01/1998 AND Order.OrderDate < 02/01/2998 NO-LOCK , EACH Customer WHERE Customer.CustNum = Order.CustNum NO-LOCK: CREATE TT_Order. TT_Order.OrderNum = Order.OrderNum. TT_Order.OrderDate = Order.OrderDate. TT_Order.OrderStatus = Order.OrderStatus. TT_Order.CustNum = Order.CustNum. FIND FIRST TT_Customer WHERE TT_Customer.CustNum = TT_Order.CustNum NO-LOCK NO-ERROR. IF NOT AVAILABLE TT_Customer THEN DO: CREATE TT_Customer. TT_Customer.CustNum = TT_Order.CustNum. TT_Customer.CustName = Customer.Name. END. END. If you monitor the network activity you will see that my simulation results in far less packets being transferred across the network. And control of program-flow is only transferred back and forth twice between the client and server, rather than thousands of times. Even so, the QUERY-PREPARE statement works so badly that I don't think I would use my server-side join strategy very often as a substitute for a nested FOR EACH. If you watch the network activity for the QUERY-PREPARE, you will see that for every CustNum in the WHERE clause, the client code has to query the database server for schema. This results in one round trip for every CustNum, even though the same schema keeps being sent back over and over. Am I missing something? Shouldn't a program cache database schema, at least for the lifetime of QUERY-PREPARE? Would the performance improve if I saved the schema cache locally and started the app with -cache?
Continue reading...
Continue reading...