>>>Yep, this application has to work on 3.x for a while, but let me
>>>ask you guys, I understand that it takes forever to load a
>>>complicated form, even that in 2.6 it doesn't, but I don't
>>>understand why it has to take forever to save or update a record
>>>in the table, I can live with some bugs, so far I have found
>>>workarounds for most of then, but every time that I need to click
>>>on "Save" I think it twice, and if you use views is worst...
>>>And I think is not a hardware problem, our low end computers are
>>>Pentium 75 with 16 mb, but it doesn't make a difference with ours
>>>Pentium 166 with 32 mb, any comments on that?
>>
>>No not a hardware problem. This all depends on how you open the tables, what relations are in place between tables, what was the sql used to generate the view and more. Moral of story is
>>
>>1. always make sure any sql is rushmore optimized
>>2. becareful of creating too many relationships between tables, especially
>>if these are coded in sections that are activated frequently like the activate event of a form.
>>3. don't load a table for a control until you need the control
>>4. don't release a form if you will reuse it a lot in the app once created.
>>5. never create large arrays (>1000 elements)
>>
>>and many more optimization techniques.
>>
>>Be very cautious about complex forms with pageframes as they can really be slow.
>>
>>Try and open tables in via the data environment it is faster.
>>Use the with command, its faster than renaming the object each time.
>
>Thanks a lot for your suggestions Todd,
>I have done everything that you say, my only question is how many
>relationships are considered too many ?, so far I need 10, and
>also in which sense is the data environment faster, because I
>don't notice the difference in using it or not, I'm going to
>try to get rid of the relationships to see what happens.
>Thanks again for your suggestions.

If you are using a View, make sure that the relations are made from the smaller table to the larger table.

Relations which are most likely to narrow-down possible results should appear first.

Try using compressed indexes for your relations between tables. My Primary key is at most 4 characters long and is a character equivalent of a Base 249 integer.

I hope this helps...