Coding is the easy part. The harder part is making the right decision on how you want to connect. With VFP you have lots of options, that's one of the things that makes VFP so powerful. Here are some considerations you'll have to account for. On how to connect
1. Pass-through (ODBC) - with this option, you'll have to consider if you want to connect to the clients programmatically, or if you wish to set up a data source name (DSN). Pro. Very flexible, very fast and powerful. Con. It can be very labor intensive 2. Remote views, this will require a DBC. Again, you'll have to decide if you want to use the programmatically connection string, or a data source name. Pro. Very easy to use. It takes care of all of your inserts, updates for you, which makes it very convenient. Con. In question is very large, It can become very slow. 3. ADO, is just another way of connecting to the server, it is very outdated, but still works. Pro. Very similar to pass-through with much more restrictions, it returns a data object that you can traverse through to pull specific data you looking for. Con. Can be difficult to work with, requires lots of additional work and if you're working with only one language in this case VFP. It doesn't make sense to use it 3. SQL Server data provider, I really never worked with this because it just seems to me, It is a waste of time. When it comes to actually working with VFP and MS SQL Server. There are some data engines out there where you have only the choice of using the data provider. It is mostly used in the.net world, guessing. For my money, when it comes to using VFP. I would much rather prefer option 1, the pass-through and handling my connections programmatically. Therefore, do not have to set up any data source names on the client machines, which is a huge timesaver and gives you much more security. In fact, all of your connection string information can be stored in a table. I genuinely use remote views for quick and dirty stuff. But I have used the remote view on a project with great success, and I do have to admit it really was a timesaver. There are all kinds of examples online and the VFP help does provide good health and examples. Be careful, VFP can really spoil you and make life easy for you. When connecting to third-party databases. So if you like me, who jumps back and forth between .net and Visual FoxPro, you start to realize how it is using Visual FoxPro <g> Cheers, Claude Mesquite Information Technologies, LLC. -----Original Message----- From: Laurie Alvey [mailto:trukke...@gmail.com] Sent: Monday, July 13, 2015 3:30 AM To: ProFox Email List Subject: Re: SQL Server 2014 There's also quite a bit in the VFP9 help file. Laurie On 11 July 2015 at 13:17, Rafael Copquin <rcopq...@yahoo.com.ar> wrote: > > I can recommend this book, which you can get at www.hentzenwerke.com > Client-Server Applications with Visual FoxPro 6.0 and SQL Server 7.0 > > > Building Client-Server Applications with Visual FoxPro 6.0 and SQL > Server 7.0 > > by Chuck Urwiler and others > > It is a good primer that will teach you the basics on how to use VFP > with SQL Server. And there are a few white papers in the web that you > can consult > > Rafael Copquin > > > El 11/07/2015 a las 0:56, Geoff Flight escribió: > >> I'm. back again. I have SQL Server 2014 and want to use a basic VFP >> program to access data in it. Pretty easy except Ive never done it >> and its been a few years since I played around with it. Can someone >> recommend a good book that could talk me thru the basics? I had Les >> Pinter's book but I have put it away safely never to be seen again. >> >> Thanks people! >> >> Geoff >> >> >> [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/009501d0bd9d$3ee0f630$bca2e290$@mesquiteit.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
