How to deal with VFP's local and remote views?

[epschaffer@gmail.com]

Thanks for now Barry, you have been a great help.

[epschaffer@gmail.com]

Hello, fellow developers looking to import your local views into Lianja,

To simulate local VFP views in Lianja, I create a virtual table for each view, using a routine to generate a script (prg); which I run from the console in Lianja.

(Discovered that the use of multiple underscores in a virtual table name is not a good idea; macro's do not work in the console; simulated NODATAONLOAD=.T. by "where 1=0", connstr="local")

Having had the opportunity to test the generated virtual tables for a few days, on tables, of max 1.5 GB, I have not seen performance reasons for maintaining virtual tables. Let me emphasize using my DBC's and environment.

I do not yet know how to quickly and easily move around or hide elements in forms. So to present a subset of the fields in records and to influence the order in which they appear, I now use virtual tables. This is most likely to change in the future.

I have dropped all my "old" virtual tables and am in the process of removing loads of indices or is it indexes, from my tables. Many existed to optimize view performance and for reporting purposes.

Quite superfluously, in order to get meaningful data from the generated views, their "where" clauses need to be replaced by appropriate values. Using the cursoradapters's requery method, does the trick for me.

After the implementation of local views and cursoradapters in Foxpro, many considered updating tables directly a No No, I was one of them. Someone mentioned to me, that I had to get rid of my old ways of thinking and start thinking the "Lianja" way. I have not been able to discover a manual yet, but I suppose that my changed opinion on the importance of views, might be a good example and I hope a step in the right direction.

[HankFay]

Having had the opportunity to test the generated virtual tables for a few days, on tables, of max 1.5 GB, I have not seen performance reasons for maintaining virtual tables. Let me emphasize using my DBC's and environment.

Reasons to use virtual tables:

1) the ability to switch backends (to mssql, mysql, oracle, Amazon's Aurora, etc.)

2) the ability to scale the database (using a common, clustered backend, with multiple LSQL instances). (Note: this requires high-speed connections, database tuning, etc.)

3) the ability to select a sub-set of records for the user to work with, based on their search criteria.

...am in the process of removing loads of indices or is it indexes, from my tables. Many existed to optimize view performance and for reporting purposes.

If you are going to do reporting the old-fashioned way (SET RELATION), you will need the same indexes to make this happen.

Can you write a web app that works against tables? Yes: been there, done that.. However, as soon as you run into a table with lots of records, you will want to select from among them for displaying to the user: you're right back to virtual tables.

Will it allow you the flexibility you need to scale, or meet customers' needs for a particular backend database? No.

Will it complicate reporting? Yes.

My $.02.

Hank

[epschaffer@gmail.com]

Hello Hank,

Thanks for enlightening me. I am relieved to have left my Xcase models unchanged

Your $.02. are greatly appreciated, as always!

Ernst