>>>>I currently have a form with a pageframe with multiple pages. Each page contains a grid from a different related file. The user views one account at a time, with each page showing the related information for that account (i.e. - one page shows addresses, another phones, etc.) This form takes a very long time to load and I want to know how I can speed it up. Right now I have all of the tables in the data environment of the form with relations set up in the data environment. As the user navigates between accounts, the grids refresh with the related information. Is there a better way of handling the data? Would it be faster to use (parameterized?) views? How can I make the form load faster? Any suggestions greatly appreciated!
>>>>
>>>>Thanks,
>>>>Elyse
>>>


I think your best approach is to use views and avoid relations and filters. I think the big advantage to this is that you can start thinking of you data in sets. Each parent record retrieves a set or sets of child data and you work with these sets and don't need relations, filters or indexes. You just have to define your views with parameters that will retrieve the correct set. You will find this very useful if you move to a SQL backend where you are pretty much forced into using sets of data. If you have optimized indexes on your tables your views will open very fast. You can test the optimization using SYS(3054) and running your sql statements from the command window.

I use relations when debugging but I avoid them pretty much entirely in applications. Same with filters. If I need a filtered view I might as well just open the view. The problem I have found with filters is when you have something like
SET FILTER TO EMPNO = m.empno or
SET FILTER TO EMPNO = thisform.empno

and the variable or the form goes out of scope and funny things happen. IF your filter uses m.empno then your variable needs to be global. Not a good idea if you use private data sessions. Of course, your filter can relate to another table field which won't go out of scope, but be careful which table closes first!

If you add a blank record to a filtered view you must add the key to this record or it will get lost from the filter. If the user really didn't want to add the record how will you know? (you've already updated some fields). With a view you append a blank record and if no data was entered, don't update!

I think overall, views make things much simpler and easier to manage. Fewer hidden problems to cause confusion.

Application design is moving more and more to SQL backend concepts which means fewer big browse windows and more set concepts (No more top, bottom, next, previous. These concepts don't really apply and we should get out of the habit of using them)