January 13, 2004 at 8:15 am
Gurus.
I need you help!!!
I do have a visual foxpro db front,back local data (it has been my world so far)but I would like to use sql server as my back-end and keep my vfp app. and a front-end.
I need to change my queries and views to get the same result from sql server, where should I start. Take it easy on me guys.
Thanks
January 14, 2004 at 4:41 am
Been there, done that... in my case way back in the days of VFP3, and I still find VFP (now VFP8) the best front end to work with for SQL.
Anyway, to start with, use the VFP upsizing wizard to copy your database to SQL. It will move structure only or data as well, as you wish. It can also create remote views of your new SQL tables that can be used as a direct replacement for the local VFP tables. The VFP engine can handle all the concurrency, caching etc for you if you wish.
In our situation we access the backend data via remote views for data retrieval, but send all writes back via SQL pass through code to get even more control over the process and to limit the amount of client code that executes during transactions.
Good luck!
Tony
January 14, 2004 at 10:31 am
Tony
Thanks a bunch, I really appreciate your input, hope do not mind been my mentor .
Thanks again
January 15, 2004 at 9:45 am
Hey foxpro guys,
Without offending you why do you think VFP is the best frontend to MSSQL?
Do you mean to manage the server or run the apps?
I've had a look on VFP (a fast look I have to admit) but I do not see the advantage over Delphi or even VB.
As I've seen you cannot create a standalone exe file or something what you could distribute to the customer. How are you managing the newer versions to be distributed?
Do you have to distribute 100K () of files when you are distributing the client or just an exe file + the MDAC 2.8 as I do with Delphi?
Bye
Gabor
January 15, 2004 at 9:59 am
Where do I start???
VFP has superb (and blindingly fast) native handling of data with its in-built data engine, so you can do a lot of post-processing on the client, taking much of the load off the server; you can just use ANSI-standard SQL as part of the language on on-memory cursors or VFP tables. It has blindingly fast string processing capabilities. Being an MS language, it integrates extremely well with other MS apps. It is truly objected oriented (alright, then so is Delphi). And so on - I don't want to preach!!!
Admittedly, you have to distibute the run-time libraries, but then you do with VB, and even the .NET langauges need the .NET framework installed. As for upgrades, I usually distribute a small EXE which references external class libraries and form code for which new versions can be picked up off the network by a run-time installer.
If you want to pursue a debate on this then see one of the MS VFP newsgroups - such discussions are commonplace there!
When it comes down to it, it is whast you are familiar with. Most languages have features at which they can be described as 'the best', but often what matters is familiarity. As long as your chosen platform can do what you want speedily, efficiently and consistently, then it doesn't really matter what it is. I have been develping with dBASE, FoxBase, FoxPro and Visual FoxPro since the 1980's. I also used Borland Turbo Pascal extensively in the days before FoxPro, but I haven't felt the need in recent years.
Tony
January 15, 2004 at 10:05 am
Prior to VB.NET, I think VFP was the best. I used v1 to rewrite a Fox for Windows app with SQL as the back end and after a year of development the OOP features made development blindingly fast.
Now that VB has added OOP (truly) I think it can be a wash between the languages.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply