When the xCase data changes, we use that to modify the (ProMatrix, enhanced by our tools) Data Dictionary, and to modify the DBF's -- this is just for development. We then use the Data Dictionary to generate the SQL Script, written in a way that for each table, field generation, restraint generation, default generation, PK generation, and index generation can be accessed separately within the script (using strextract)). Using the existing SQL DB, and the DD from the new EXE, we create field-matching etc. (xCase ID numbers are stored as extended properties in the SQL DB for every table and field) and update the SQL DB in place.

Now, of course, we are embarked on creating the same set of tools for Lianja, adjusted to the strengths of Lianja, and informed by our experience (10 years now) using the tools in creating small and large applications. The new toolset will be a lot better, partly because of what we've learned, and partly because Lianja has been very good about putting into the system things that we (and other developers) have said we need. Doing so has probably cost Lianja many months of delay in getting to release, but from my perspective, at least, V.1 does what we need. And we have enough experience with them at this point that we know it will continue getting better.

Hank

>That sounds pretty slick too. I actually started out doing it the way you described - heck I was even using xCase! Anyway the conclusion I came to is that while this does have it's benefits you still end up with a bunch of stuff that is specific to the backend you're using...so anytime a change has to be made it causes significantly more work.
>Now keep in mind that if you're not the one that has control over the database table structures then it changes the game a bit - and doing it this way as opposed to what I've been doing will probably be worth the effort.
>
>>Hi Charles,
>>
>>we do it with no lines of code: throw an ini-file flag and everything switches over. The DBC gets changed in DataEnvironments in the BeforeOpenTable event. The ConnString gets added in the 1 routine that opens a view.
>>
>>Our way consists of designing in xCase; from which we generate the local DBC. We use the local DBC to generate a remote DBC, massaging the SQL of the local DBC to fit SQL Server -- that process itself is data-driven, although the data in this case is a template in a memofield that controls what we call the function substitution engine. We have an app with 650 tables; and about 1400 custom views (and a set of generated views for each table and table/relationship). Out of all those there are 1 or 2 views that are hand-coded (the code for local and remote gets put in xCase, and the right code gets put in the right DBC).
>>
>>Frank Camp did most of the work on making this work, BTW. Brilliant guy.
>>
>>Hank
>>
>>>PMFJI -
>>>
>>>I came from the YAG Codebook tree and VFE began there in its approach to using remote views. We believed at one time that with lv_ and rv_ and the stuff we had in the framework we had acheived "all you gotta do is" for switching from local ( against VFP tables ) views to remote ( SQL database ) views. Our cursors would work against v_ remote views and with the flip of a switch we could go from local to remote. Great theory and in fact with three lines of code we could have the views look at VFP data or SQL data quite easily. And in carefully crafted demos it looked really cool, like the stuff one dazzles crowds with in "all you gotta do" demos at conferences. ( remember just dragging a table onto a VFP form and having the audience go "Ooooh" :-)
>>>
>>>Spent the last 10 years of my VFP development doing all my own development against SQL databases and mentoring a lot of projects and doing a lot of conversions of DBC/DBF projects to SQL Server and I never saw a case where anything but the simplest remote views worked against either backend. Syntax just too different for anything beyond very basic stuff. Typically out of 200 remote views written against VFP tables I could use 30-50 without syntax changes. Yes, two different views DBCs - one for VFP and one for SQL could work but I just never was able to get around some very basic stuff about VFP vs TSQL remote view syntax.
>>>
>>>Have you really figured out how to get around this? When you say you can switch to any backend with three lines of code you are describing something I never saw in practice.
>>>
>>>>>No, I understand what you're saying, but I think it's more of a disadvantage than an advantage. I just don't see why you think it's such a great idea.
>>>>
>>>>ummmm...because by running 3 lines of code I can have my app connect to any backend I want without ANY extra work. That's a really nice sales pitch when you're dealing with a client or potential client.
>>>>
>>>>>One other thing...you have to keep SQL statements to the lowest common denominator. That means you also can't take advantage of many features in the backend server.
>>>>
>>>>Yes that is indeed a disadvantage...but I've never run into a situation where it mattered. (yet)....and for me it's worth dealing with the lowest common denominator to have the flexibility of multiple backend choices. If you were selling a vertical market type of application having this advantage is an outstanding benefit.
>>>>
>>>>
>>>>>>I just don't get it??
>>>>>>
>>>>>>From what I see there is no simple way to switch all of your local views to remote views without creating another set of views. There is not some simple 3 line property change like what I can do to switch connection strings to do this - your stuck creating another set of views...thus doubling the workload anytime you make structure changes.
>>>>>>
>>>>>>>Oh my, no. Tables/database, etc should be opened in one location. Again, your way will have slower data access and limits you to VFP 6 and earlier features. It also takes more memory.
>>>>>>
>>>>>>What do you mean by "one location" ??
>>>>>>And yes I realize that using the remote views limits me to VFP6 features - but that's not been a problem for me and by doing so I've made switching backends seamless. The slower data access is so miniscule (if there actually is any) that's it not even noticeable to the user. As for the memory - well if the views are designed properly it's not that much memory and PC's these days come with more than enough memory to handle these things without having to worry about it. And how does a remote view use more memory than a local view anyway?
>>>>>>Sorry to keep pestering you but I really want to understand all this :)