Bob-
I looked at your email several times. I just now had the chance to test and evaluate based on your thoughts and I cured a few issues I had in a computed column that I was pulling into this temp table then temp view. I read your advice on the index common columns but they are reoccurring and not really unique (like 30+ repeated times out of 67k rows). I believe this fails the index rule as I know it. ;( But now! I now have a nice message telling the user that the db is preparing the data (NO crtl-alt-del Please Mr. User!) and then taking that whole temp_view and projecting it into a temp_table. I tested the db_grid and scrolling region based from this temp_table and they both fly like I would expect. I will now clean up the sql and clear up a few steps. Thank you! for your examples and saving me time not testing in areas that would not make a difference. Paul D Thank You RBTI for the speed that is available in this db engine, I recall the dos days and this would have taken hours if not days. From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, January 21, 2010 6:48 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: form /db grid / network I guess I did not respond to a lot of the original question. (Got a phone call and was side tracked) There should be no speed difference between a temp and static view. Proper indexing on the tables is a must for performance when using views. (Either type) The linking column needs to be indexed. Rule of thumb... the fewer the linking columns, usually the better performance. But they need indexed if the tables have larger number of rows in them. In my experience, it seems that reports are faster when temp tables are used versus views. However, this is not scientific proven, just my opinion. I am not sure about DB grids. I would not expect compacting the form or compiling would effect the db grid speed much. Compacting might cause the form to startup faster, but not perform faster. If your view runs very fast with a select command, but is slow in the form DB grid, you might have double where clauses. I.E. your view definition might be "Where t1.part# = t2.part#" and then your DB grid where clause be something else, such as "Where company = 'ACME'. You might get better performance using a temp view, defining it at form startup or even when moving into the dbgrid with the single where clause "Where t1.part# = t2.part# and company = 'Acme'. This is another reason to use tempviews. Create them on the fly. The above is not a confirmed logic. I am unsure if the the DB grid executes the view first and then narrows the data. But if so, having two where clauses would be slower. -Bob ----- Original Message ----- From: "Paul InterlockInfo" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Thursday, January 21, 2010 5:10:36 PM GMT -06:00 US/Canada Central Subject: [RBASE-L] - Re: form /db grid / network Thank You Bob ;) I will quit manipulating the views etc.. and concentrate on form options/settings. Sincerely, Paul Dewey
