> One thing we do that I found importan is that we keep the containers with the view definition on the client machine, every time the application starts

Why is it important?
I copy Foxpro's database containers to client machines only for the reason of providing a "personal" db container to each user. I don't think it'll make RV work faster.
Can you explain?
Thank you.


>Hi Randy, I can only tell you about my experience, I can not
>tell you whether your approach is the best or not. I tried to use Server Side views at the begining and only got frustration.
> What worked really good for me was to use FoxPro remote views to access the SQL data, and why not?, there are meant for that and they work wonderful, plus you have all the
>data manipulations benefits that FoxPro offers and you are already familiar with most of them.
> We do have triggers and store procedures in the server side, but most of the work for the data manipulation is done in Fox, either through Remote Views or SQL Pass-Through.
> One thing we do that I found importan is that we keep the containers with the view definition on the client machine, every time the application starts
>we compare the datestamp and shift the containers to the client machine
>when the daystamp doesn't match.
>
>Check this two utilities I uploaded here :
>Download #32101, lets you create a DSN on the fly by writing to the registry
>Download #22850, lets you convert a cursor created with a SQL Pass-Through so in can send updates to the back end.
>
>Good Luck
>
>
>
>
>
>
>
>
>
>
>>I am just beginning with SQL Server, looking to begin very gradually migrating our VFP databases and tables to SQL Server and adjusting our VFP applications accordingly. I am still studying SQL Server, working through various books in connection with SQL Server Developer edition, not yet far enough along to have actually performed the physical design, etc. I am thinking that it would be better to so design the views, stored procedures, triggers, constraints, etc., so that SQL Server performs any actual inserts, updates, deletes, generation of views, etc. VFP could request already-defined views, manipulate data locally which could then be passed to SQL Server for processing by stored procedures, etc. I am thinking the VFP should not be permitted to directly access the SQL base tables to create its own views, or perform any direct data modifications. I am thinking that the other VFP developers and I can collaborate to set up the views, etc. so that applications will have what they
>>need available, without needing to delve into the SQL tables directly.
>>
>>Is this a reasonable approach, or just a sort of "purist" approach? As we have been seeking to grow in n-tier design anyway, it seems like a proper approach, but as I said, I'm just an early beginner at this ...
>>
>>Thanks,
>>Randy W.