Re: Performance problem on client/server
Posted in 1996
Topics: Performance & Tuning, Error Codes & Troubleshooting, Connectivity: ESQL/C, 4GL & Embedded SQL, Jobs, Consulting & Announcements
billy@west.co.za (Billy Wheeler) wrote: >> To get this behaviour out of a 4GL program would be very hard indeed. >> 4GL is so different from VB in the way it interacts with the db you >> shouldn't think too much about that. >Nils, unless I'm missing something here (which I could well be doing! :), this >seems to be very much the way VB would work - all the client on machine A, all >the data on machine B, and data transfer across the network becoming a major >hassle. >It might be better to transfer as much of the reseource from your client machine >to your server as possible and run without the client/server approach... >But on the whole, I agree with Nils - we would need substantially more info >to address this. It might be worth your while to get a good consultant in. >-- >Ciao, >Billy >+------------------------------------------------------------------------------+ >| Billy Wheeler Junior Programmer / Director The West Solutions Group | >+------------------------------------------------------------------------------+ >| (E) billy@west.co.za (U) http://www.west.co.za/billy.html | >+------------------------------------------------------------------------------+ >| "No, Woody, I said _TUCK_ the kids in bed..." | >+------------------------------------------------------------------------------+ I think we are missing the question here... so let me restate it... Suppose on machine A defined as client and running all programs including batch jobs we execute a 4gl program that runs on A against data residing on B, defined as the server. Suppose a program does the following. LET f_prepare_stmt = "SELECT from table where table_id = ? order by invoice_date" PREPARE select_records FROM f_prepare_stmt DECLARE select_records_cur CURSOR FOR select_records and then later on... OPEN select_records_cur using id # id was previously gotten IF SQLCA.SQLCODE = 0 THEN FETCH select_records_cur INTO f_record ....... For those of you who think this runs slow on the developement machine C, I dont care. What I am concerned about is whether or not the above code results in the entire table being loaded to the client and the SQL statement executed on the client. It is my hunch that this is in fact what is happening as it would in a VB or DELPHI client/server relationship if not done properly. The program in question does one select against 60000 server rows looking for non printed invoice... once it gets the population it gets data from subordinate tables each with the same id indexed as unique and using the above technique. Again I dont care if the code sucks on an isolated platform... what I want to know is whether or not the code results in the who table(s) shouting down the network??