How is it a PITA doing it my way? One set of views in one DBC - done. Want to switch backends?- Change connection string - done! No recompile or anything required. Like how simple can it get right ??? hahaha




>I see, sounds like a PITA in either case.
>
>>Since you can't have a local view and remote view with the same names in the same DBC you'd have to either have two different DBC's or abandon using form's data environment and write code for every view that is used to a) be sure you got the right one and b) give one set an alias name the same as the other set when you opened them. Either way you've just doubled your workload if not more.
>>As I said by doing that you can't put the views in a form's data environment.... and you still have to change all your code around so the app will know if it should be using local views or remote views. So everywhere in your code where you USE a view you have to tweak it to know which one? Plus this also means you now have two sets of views to maintain in the event of any changes.
>>
>>I dunno it sure makes a heck of a lot more sense to do it my way using the same set of remote views and simply changing the connection string. One set of views and same code runs no matter what backend - much better yes?
>>
>>>You don't need to change the control sources. It should be the view opened with the same name, so your code should not be changed. Just in case of local data it will be local view (opened under generic viewname alias) and in case of SQL Server data it will be remote view.
>>>
>>>>What do you mean by 'no waiting'?
>>>>I actually have no problems using this approach - the issue I'm having this time isn't because of my "one remote view for multiple backends" approach - it's because of flaws in some other existing VFP application that I inherited.
>>>>
>>>>I'm still a little confused on how your idea of using local and remote views would actually work. Wouldn't I have to change the control sources? If I have myremoteview.myfield for a control source I'd have to change it to mylocalview.myfield when switching between backends right? And what about the miles and miles of code in the app that uses the data from all these remote views to do things? I would have to go back and tweak all that to use a different set of views if switching backends? Plus now debugging would be harder as the same set of views & code doesn't run for multiple backends...not to mention that every time there was a table structure change you'd have to make two sets of changes instead of one. I've actually been doing this since 2001 and it's worked great thus far. I've connected the same app using the same remote views to VFP, SQL Server, mySQL and Oracle backends with no need to even recompile. I've only sat down and thoroughly gone over how I'm doing this with 2 other VFP guys - both of which are now using it.
>>>>
>>>>>Two Views, no waiting. No, you don't need to change the control sources. Reports depend on how you set them up. You may only need one view, but you are running into issues with it. So, you're trading one set of problems for another. IMO, the problems you have to deal with are bigger.
>>>>>
>>>>>>But if I do that - then I need two sets of views though right? One set of local views (for VFP tables) and one set of remote views (for SQL tables). Then on top of that I'd have to write some gizmo to deal with all the control sources of all the controls on my forms and reports because those would change as I'd be dealing with two sets of views. Using my approach it's the same view either way so all those problems don't exist. ....or am I misunderstanding something??
>>>>>>