Roy
|
| Posted: 05/23/2002, 3:07 PM |
|
SQL string causes memory problems
I am using the following SQL string in a codecharge grid form:
------------------------------------------------------------------------------
select users.user_id, users.first_name, users.last_name, users.address, users.city, users.state, users.zipcode, users.country, users.phone, users.fax, users.email, users.pay_type_id, users.cc_number, users.cc_exp_date, users.cc_hold_name, users.arr_date, users.dep_date, users.arr_airline, users.arr_flight_nr, users.dep_airline, users.dep_flight_nr, users.acc_staying, users.room_nr, users.visit_plus_nr, payment.name, tmp_acc.order_id, tmp_acc.user_id, tmp_acc.acc_id, tmp_acc.check_in_date, tmp_acc.check_out_date, tmp_acc.number_adults, tmp_acc.number_children, tmp_acc.quantity_acc, tmp_acc.arrival_time, tmp_acc.special_request, tmp_acc.vendor_id, vendor.vendor_name, vendor.vendor_email, accommodations.acc_id, accommodations.acc_name from users, payment, tmp_acc, vendor, accommodations WHERE users.user_id = tmp_acc.user_id AND tmp_acc.vendor_id = vendor.vendor_id AND users.pay_type_id = payment.pay_type_id AND tmp_acc.acc_id = accommodations.acc_id
-------------------------------------------------------------------------------
Okay this sql string is pretty big. At the moment I start adding the fields to the form
Codecharge messes up the screen. My system resources proces as follow. 77% normal, 60 after Codecharge started. 41 % after I open the file with the SQL string. My system has 256 mb of
ram, so that should be enough. I have to admit that the file contains two different forms with this kind of sql strings. Is there anyone who had the same problem before and knows how
to solve it.
Kind regards,
Roy
|
|
|
 |
Alex Alexapolsky
|
| Posted: 05/24/2002, 1:00 AM |
|
Not sure if this is caused by such small strings.
What is your CC version ?
|
|
|
|
Roy
|
| Posted: 05/24/2002, 5:10 AM |
|
I am using Codecharge version 2.0.5
|
|
|
|
Nicole
|
| Posted: 05/25/2002, 2:15 AM |
|
Roy,
have you tested query to count the number of returned records? When you use custom query as form source CC executes the query to get the field names and aliases. In case there’s a lot of records returned it may slow CC and decrease free system resources
|
|
|
|
Roy
|
| Posted: 05/27/2002, 12:56 PM |
|
The number of returned records is very small. The program is in design phase and there is hardly test data in it.
I hope somebody can help me further.
Do you have other suggestions Nicole?
Roy
|
|
|
|
Roy
|
| Posted: 05/29/2002, 12:03 PM |
|
No the number of records returned are very small. The application is in design phase so their isn't much data in the tables.
By the way I tackled the problem as follow. First I created the forms in separate pages and then I pasted them in one page. The only disadvantage is that if you want to edit the forms after words, you cannot do it on the page were all forms are pasted. You have to adjust the original and cut and paste again.
Unfortunately not a very nice solution. So if anyone know's something better, it's welcome!
|
|
|
|
Denis Delarze G.
|
| Posted: 11/28/2002, 7:50 AM |
|
The SQL in any data base works this:
first make cross product for the joined tables..
numreg(users) x numreg(payment) x numreg(tmp_acc) x numreg(vendor) x numreg(accommodations) = too much registers
later the result is filtered by Where clause..
try using sub-select
|
|
|
|
RonB
|
| Posted: 11/28/2002, 12:29 PM |
|
I'd split up the pages, keep a few fields from your select statement on the first page and create a details page for the rest. If all the fields in your select statement are shown on one page it would become unreadable anyway. To much information on a page will prevent users from taking in all that info. Dividing the info over 1 or maybe even more pages will serve all that info up in small and readable sized pieces wich users can digest more easely.
Ron
|
|
|
|
|
