Re: Transferring Database to SQL Server

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Peter Rooney" <magnetix@xxxxxxxxxxxxx> wrote in message
news:HJqdnZFD5qNRH8_UnZ2dnUVZ_q7inZ2d@xxxxxxxxxxxxxxxx
You will be pleasantly surprised at the SQL software technology.
March into it!!!

Ha! I have been using it for some time now. It is in VFP. SQL
is a hodgepodge language though.


So is VFP. How could it not be, while being largely backward compatible?

My original question was, why is it required to switch from DBFs to SQL?
especially if this invalidates a large part of the core language, like
USE?
If I have a single-user application, I hardly need security. Or even if I
have a small network of 5 users, they are not malicious and know to stay
out each others' way.
So is a switch to SQL even advisable with a small application?


It depends. How critical is the data? How often do they back it up? How bad
would it be if the database was not available for an hour or two? How bad
would it be if it crashed today and they lost everything since the last
backup? If you don't need security, do you need stability and reliability?
Is this a mission critical application?

FoxPro tables are usable and fast, but will never be as stable or reliable
as a good back end database. With a single small installation, you will
probably have few if any problems. I'm working with an app that has about
140 separate tables and is installed on several hundred servers across the
country. And I see data corruption on a weekly basis, sometimes daily. Over
the years we have lost a lot of data that was stored in memo fields, and a
lot of the individual records themselves.

Our Oracle and MSSQL databases don't have this problem. I've only lost one
MySQL table, ever, and that was when I was doing some tests to see if I
could crash the server (I could - bye bye 5GB of data :) FoxPro tables in
our enviornment have a fairly consistent failure/corruption rate. It is
small rate, but if it's your bank deposit that gets lost you won't think
it's that small of an issue.

I won't use VFP tables on any new apps. After 20 years of FoxPro, I've seen
too much data loss to ever trust them again.


.

Relevant Pages

  • Re: Transferring Database to SQL Server
    ... It is in VFP. ... SQL ... is a hodgepodge language though. ... Some people have complained about FoxPro data corruption, ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Transferring Database to SQL Server
    ... It is in VFP. ... is a hodgepodge language though. ... why is it required to switch from DBFs to SQL? ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Transferring Database to SQL Server
    ... It is in VFP. ... is a hodgepodge language though. ... why is it required to switch from DBFs to SQL? ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Select - SQL vs. SUM
    ... If you have to use an earlier version of VFP earlier than 9, ... >> also force VFP to read from the buffer with a new clause in the SQL ... >> The SELECT command doesn't move the record pointer in the grid's record ... >>> I have a grid whose recordsource is a table named _payments. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: SQL2000 data access via OLEDB
    ... We were having some issues with VFP with SQL 2000. ... Is it true ADO is needed to wrap access via OLEDB, ...
    (microsoft.public.fox.programmer.exchange)