You don't need to manually configure a DSN entry on each client machine to access a SQL Server backend. You simply need to get the ODBC driver installed. This can be automated to kick in when a user logs in to their network or worst case, you send out an email with a link to the .exe and have them manually run the set up one time. I've had the network guys do this for my clients and it works great.
Then, you simply have the application create the connection string and use SQLSTRINGCONNECT(). I prefer this approach since I can also easily change the server ( ie hit a test server vs. production server ) by changing some configuration options in my application directly. Of course, installing the SQL backend is a manual process. To a certain extent I think that can be automated too, but I've never investigated if you can fully automate it with some kind of predefined defaults or something, but perhaps? Thus, if it's not possible to fully automate the SQL backend install process, *and* you have tons of different customers to install it to, I can see why moving to SQL would be a difficulty for your situation. Alternatively you could consider hosting the SQL server at your own company or by 3rd party remotely and have each client hit that one server ( or partition into several if one would be overloaded ), and simply have the application use different databases for each client to insure data security. This way, installation of the SQL backend is simple. The downside is a bit slower data transfer than running on a LAN, and also overcoming possible customer concerns of data not hosted outside their own building. -Steve At 01:21 PM 07/16/2010, [email protected] wrote: >We did the same. We had several old time clients who were over 1.5 >gb in their transaction table. We split it putting >charges in one table and non-charges in another. We believe that >will buy us another 5 years. > >I checked out that link someone sent for the Advantage stuff. It >looks good. I especially like the tools they have. > >We have several thousand client installations all over the US. It >will be impossible, at our current support rates, to >consider setting up a DSN on each computer manually. In fact, the >installation and setup is the primary reason we have >not moved to SQL already. We would like to use Postgresql and have >an automated way to set it up so that a current >client could install an update as usual and have it automatically >migrate everything from dbf to sql. Our clients have >an unbelievable number of different hardware configurations. I dread >to think about all the possible issues. The actual >VFP (or Python) programming is not the problem as I see it - it is >that manual SQL administration stuff that is the >problem. Most of our clients are small offices and do not have very >much IT expertise around. We need a royalty free way >to do it. Our clients are not going to pay a per-seat charge and we >don't want to do the accounting. Also, we need to be >able to deliver a turn-key product so our users don't need to >download anything or manually install anything or go >through a lot of complex procedures. Probably half of our clients do >not have internet access. Many are still using a >modem connection to transmit their files to various payers. > > >----- Original Message ----- >From: "Ken Kixmoeller f/h" <[email protected]> >To: "ProFox Email List" <[email protected]> >Sent: Friday, July 16, 2010 9:50 AM >Subject: Re: Large Data Tables > > >Kent Belan wrote: > > Hello, > > I have a client that has been going along great for the last 10 > years. He is > > now ready to explode. > > > > We are pushing the 2 gig limit now on the client table and he wants to add > > tons more. > >(Anticipating flames, I say this softly...) > >A band-aid approach that may be expedient in your current circumstances: >Stay ancient and split the offending table. Many years ago, I had an >old-style Fox application (I created in FP [2?] and migrated to FP-Win, >then to VFP). It had one table approaching the 2G limit. Since it was >only one table, I elected to split it (vertically: fields 1-40 in table >A, field 1 [PK] and 41-x in another). > >It didn't take too long to update the forms and reports. You might even >find it just as easy to upgrade some of the data access language to SQL >for SPT, or even build a data object for it. That may buy you time to >upgrade the application to modern standards without holding the client >back while you do. > >(Flame away, PFers!) > >Ken > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** 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.
