>Well it seems I you guys agree. Views should not be used on local data if you want speed.

I'm not quite sure if that's the way it works. After all, a view is nothing more than a *special* SELECT statement that creates a record set that *can* update the base table, as opposed to a plain ole' SELECT statement that can't. How much info is pulled out of the original table, or passes across the network, is the same. In fact, as I understand it anyway, the only way you can cut down on network traffic with a view is if it's a stored procedure in a database...be it Oracle or SQL or ???. If it's not a stored procedure then you still have to get the data to *thinking* machine regardless of whether you're using an ODBC driver or not. A stored procedure works at the database server and only passes the final results of the *view*, not everything it took to get you there.

I think a real bene of view is in the data processing arena of the form itself. If were talking about a one to one data process (adding/editing a customer record) it's six of one or half dozen of the other. But if we're talking about a one to may situation, like an sales invoice or payables voucher or payment processing for either A/P or A/R, a view is a much more efficient way to do go...*especially* in the edit mode of the transaction, since the options are:

1. A filter...blaaaaah, creepy & crawly
2. Pull the records into a temp *table* and when posting delete the originals and putting back the new ones.

Either way you cut it, they can't compare to the beautiful simplicity of working with a view. Do what you want to the transaction and then issue a TABLEUPDATE() or TABLEREVERT().

>But if you want to help your marketing efforts and ease the conversion to SQL use views.

My experience has found view to be a *very* time-saving way to work with data. Once you have a table created it takes about a minute to create an updateable view and just as long to stick either one into a form's data environment. The only drawback I've found with views was changing my thought process while developing the app...but that didn't take all that long...and now I can't imagine writing an app that didn't use views, it would seem like the hard way to do it.

>This last one appears to punish the customer if they have large amounts of data and forces them into the expense of SQL.

I don't see the difference between more money for data vs more money for office space...if you need it you need it. The options are purge you data and work in the street ;)

>Most of my customers will not be switching to SQL for years if ever. Would it be better to create two (maybe 3) classes to cover how the data is seen???

I don't know if multiple classes will solve the problem...ever if they were subclassed the glitch is the controlsource...which would have to change with the name of the table. You can have the same view name in two different dbc's, but you can't have a view with the same name as a table in a dbc.

But that's not really the issue. If you're coding to client/server, the code is virtually the same whether the dbc is VFP or Oracle or SQL. The difference comes in when you don't code to views. So even if you had 3 dbc's, you would have to write alot of code twice...once for the non-view version and one for the view (Client/Server) version.

I think the easy way out is to write the view (Client/Server) version, with it's data processing benefits mentioned aboved, and stop there. Then, when you do indeed need a client/server version, create your new dbc with it's remote views useing the same table names and structures, stick the logic in the load of the app to select the correct dbc, modify any select statements you have to match with the database engine in play (SELECT statements in VFP will not always work with another engine...eg SQL-Server nor Oracle can interpret an IIF(). This will take you a whole lot less time than redoing the whole application :)