On Thu, 2003-07-31 at 13:54, Chet Gardiner wrote:
> ----- Original Message -----
> From: "Rick Romero" <rick (at) valeoinc DO.T com>
> To: <profoxtech@leafe.com>
> Sent: Thursday, July 31, 2003 5:12 AM
> Subject: Re: Visual Record Lock?
>
>
> > On Thu, 2003-07-31 at 02:12, Chet Gardiner wrote:
> > > I've never had "data problems" with DBF's.
> >
> > I have. Too many times. I semi-regularly have to clear out large DBF's
> > so they can reindex properly (1 user on the network - doing the
> > indexing).
> >
>
>
> What do you mean by "clear out".
Not empty, but remove data until it indexes properly.
>
>
> > I can burn/create ISO's left and right on the network, but Foxpro DBF's
> > can't handle it.
> >
>
> What?????
Yep. DBF/CDX's are the only large files that have issues.
>
> > > The only problems I've ever had were with power failures,
> > Not here. Building UPS.
> >
>
> You mean, no users cut the power on their workstations in the middle of an
> application?
Nope.
>
>
> > > network glitches,
> > ?? No such thing. You either have a hardware or software problem. Or
> > your DBF's are too big.
> >
>
>
> Guess what, network software often has bugs in it. That's what I meant about
> "network glitches".
As long as you recognize it as that. I just want to be sure people
understand that there is no "troll in the ether" eating packets.
>
> > > index corruption (usually network problems)
> > Sorry.. Network problems that only affect DBF/CDX's are not network
> > problems, they're application problems.
> >
>
> Since Intel processors are single-threaded, and the DBF buffers are written and
> THEN the CDX buffers are written (or vice-versa - depends on the Foxpro
> version), not simultaneously, there are ample opportunities for flakey network
> software/hardware to screw up.
I'll give you flakiness can have a hand in a problem, but the consistent
factor is Foxpro and large DBF/CDX's.
>
> > > and tables >2GB. I suspect that
> > > most of these problems would mess up back-end databases too.
> >
> > SQL? Nope. Never had the same kind of issues with SQL tables.
>
> I said most of the problems... I know that SQL server can hold more than 2GB.
> (I figured I'd give you something you could complain about-- Gotcha!)
If you think so ;) But the DBF/CDX's that get corrupted aren't anywhere
near 2GB. IMHO, what makes the difference in SQL vs DBF is that the SQL
server is doing the reading/writing locally. It's centralized.
DBF/CDX's are not centralized, everyone is essentially fighting for
their spot. (I don't suppose you ever had Memo field problems in FPD
either ;)
> It's just harder to configure, store, maintain, and get at the data with the
> more complicated backends. Who the hell needs the expense and hassle for
> smaller business database applications?
I just use MySQL, and phpmyadmin. I don't use views, I do a general
select and work with the cursor locally. Of course, that method may not
work for you.
> ---------------------
>
> This is really my point - the "either/or" crap finally got me to post this.
>
> It seems to me that most of you SQL server/Oracle proponents don't do small
> business systems. I know that I don't do "large/enterprise" systems.
Actually, I'm all alone here, with a total of maybe 12 office people ;)
I was in at credit card processor with a good 200 people. Different
software, Same VFP, Same issues. <shrug> Therefore, I still with my
"Would you please use and SQL server" comments. Except now I have the
power to make that change myself, instead of begging the programming
group to do something. (RANT - Because it was ME driving downtown every
freaking weekend, and getting paged at night to fix their sh*t - TY.)
> Most small business systems just do one job, do it well, and are scaleable
> enough (very few small/meduim size businesses turn into General Motors, folks.).
> That's why there are so many DOS systems hanging around. They do the job, the
> employees know how to use them...why change?
You're preaching to the choir here. The guys at my last job have been
bought out and are slowly being closed down. They STILL haven't gotten
rid of the OS/2 box I setup in '96 ;)
My only beef with VFP (well, other than it being Windows only, and
licensing issues ;) is that I've seen quite a lot of corruption when the
tables get large.
We run SBT Pro 5.0 here. There is a SINGLE DBF for history data for
each 'module'. THAT is the table that gets corrupted most open. IMHO,
that's an application issue with SBT, even if it was in SQL. History
should be split up into month/year DBF's. Unfortunately with VFP,
having a huge DBF/CDX just bites you sooner.
That's just my experience.
Rick
>
>
[excessive quoting removed by server]
©2003 Rick Romero |
