>>Keeping the amount of data read from the backend restricted (to a minimum) often is the main worry in upsizing a xbase style vfp app.
>>
>>That said, with a generic searchform/a way to use the form as search parameter finder and some overwritable defaults (select those records changed by user up to n days before *his* last commited change if no filter is presented) you often reach a workable solution for most forms when switching over to views or cursoradapter.
>>
>>All in all, as long as the app already is already working on tablebuffering IMHO you have good chances to upsize without a total rewrite - if the app code is "worthwhile" at all.
>>
>>regards
>>
>thomas,
>
>Greate reply, so, if I understand correctly, you are saying that if the application is already multi-layered in design with the proper handling of user interface design then you won't have to revisit those issues in too much depth?

Yes - but even in single tier approaches you can get a lot done for C/S if it follows a pattern / inheritance is used and you don't have duplicated framework functionality.

>
>That is my whole point, how many times have I seen the application using VFP local data present the user with a pageframe and on page 1 is a grid with all the customer records displayed for the user to choose the one they want. There is a search button to help them but the grid is there with all records in it. If that form came up with a search action as the center of the first page and no grid, then it is already designed for dealing with the large data bases that an upsized application needs to deal with.

I am currently upsizing a similar app - developed by the company owner in the last 20 years with some stretches of other programmers helping in between and integrated other components. It is a curious blend of sometimes surprisingly well working ideas with a few horrible solutions to get it working "today". My second point is that even in those "show all records at first" forms a sensible default filter can be applied: show the entries the user has worked on in his last sessions. Easily done by adding [Created,Modified][By,Date] fields as standard fields to all tables. Cleaning up the code where such info previosly exists with different field names will be done in a second wave. This approach has not failed once yet in his app (shown by some automatic logging of records read and time needed) - and in case one employee recalculates prices of stock items by applying percentages such screens would be targeted for non-default filters or the order of screens shown can be changed<g>.

Lookup tables are read in total by choice and and only flags signifying needed Cursorrefresh are checked for them. This allows me to keep server side join activity down for the more elaborate grids previously based on many tables in relations. I could have left the existing code and set relations to those "shadow cursors" for a pure fat C/S solution, but here I massage the local "grid" cursor with the lookup info to get a cleaner model possible to reuse in a 3-tier setup with an simple call to CursorToXml(). Since all his forms are inherited from a common 1-tier template this rearchitecting is possible. Relocating validation and biz code will be most work to turn it into 3-tier, but this *can* be done without a total rewrite.

As long as redundancy is not rampant in the old code for me the thing is to find the "good parts" inherent in the old code - even if this means that I have to adjust my style to the original developer. Most of the times there is quite a lot of good from the original designer who was able to create a working app. For me the really bad scenarios are those where different maintainance drones did not recognize the drift of the design and added their "necessary" patches sometimes even N-fold at the wrong places.

regards

thomas