Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Business Case for VFP
Message
 
 
To
11/01/2013 20:02:23
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows 7
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01561746
Message ID:
01562278
Views:
60
>>Maybe there is something I missed for a long time. My understanding was always that you could issue any valid VFP SQL statement against the view, local or remote, and it would work. VFP handled the update against the database. I'm sure if there was VFP specific syntax in the WHERE clause it wouldn't work, but I didn't do that.
>>
>
>Ultimately remote views are just wrappers for SPT. If the syntax works, the view works. There are enough syntactic differences between the VFP and TSQL versions of SQL that it is easy to blow it up. Example: you can do a view of view in VFP. SQL hates that. I have a whole list of them someplace as I was doing so many conversions of VFE projects ( where I had taught everyone to always use remote views and never code against tables ) that I wrote a program to analyze views designed to work against DBCs and find those things that weren't going to work against SQL. That was all it took, thanks to Mike and Toni's brilliant design of the framework itself, which really loved SQL Server. We always taught keeping views in their own DBC, so once you had created a views DBC tailored for SQL you actually could run the same app against either VFP or SQL data, but the views DBC had to be crafted for the backend.
>
>A big difference, in practice though, was that it was easier to use GUIDs for pks since you could generate them for new records ( and hence populate fks in children ) on the front end. That was fine (even before sequential uids were introduced in SQL) for smaller apps where index insert speed and table size wasn't a huge deal. But most existing SQL databases would employ identity keys, so we had some magic in our datalayer to handle syncing the newly generated parent pks with the fks in the new children when there was a big save of a new parent and multiple child table records at one time. So a lot of times the "upsizing" would include rethinking pk / fks
>
>In my big project rescue job at Dow Jones this was a very big deal, as the tables were quite large and the existing app was doing some stuff that was ... creative - but stupid :-)

Dow Jones past tense? That sure sounded like a sweet deal for you.

I recently completed an outsourcing gig on a large commercial app. It is nicely written. One of the things I liked was the use of separate view DBCs for different back ends. All you have to do is swap in the right view database, no source code changes needed. To me that epitomizes elegant and versatile software design.

Are you still in contact with Mike and Toni? I see Mike on Facebook sometimes, along with his redneck friends ;-) He had a great photo posted for a while of he and Toni skydiving together on their whatever anniversary.
Previous
Reply
Map
View

Click here to load this message in the networking platform