🚀 go-pugleaf

I thought I wanted to migrate MS SQL Server, but then I read the various
threads in this newsgroup concerning the use of it or similar dB servers. 
So, in my never-ending quest to consume bandwidth, I want to re-kindle the
debate, but this time, within the context of _my_ scenario.

I have a VdB app that I wrote to handle the logistics side of the part of
our business that generates 85% of our revenue.  It's main table has 100 to
200 K records at any time during the month with 88 bytes per record plus a
memo field.  The table is a DBF and I use DML exclusively - no SQL.  I need
two more apps: one to automate a paper-based part of our  business that
generates the other 15% of our revenue; and another to replace a DOS
clipper program that a 3rd party wrote for us many moons ago to handle our
invoicing and accounts receivable.

My first reaction was to build the two new apps with VdB, but I don't have
the time, and other people have already written apps to handle these, so
why re-invent the wheel?  But, our highest priority with systems is that
they be highly, and preferably, seamlessly integrated.  At the very least,
I don't want multiple copies of tables (like customer files) existing
simply because the apps don't want to (or care to) share data with other
apps.

So, the solution I thought I came up with was to purchase apps that use MS
SQL Server to get their data.  Then, I would simply convert my existing
apps to use MS SQL Server instead of DBFs.  But, it sounds like I'm
probably going to take a performance hit on my main app (which runs slow
enough as it is) if I convert to MS SQL Server.

Am I wrong?  Is there a better way of doing this?  Am I better off building
the two new apps in VdB with DBFs?

BTW, I have about 6 users on an NT 4.0 network, but the main app resides on
a Win95 "server" for logistical and cost reasons (I can upgrade it to NT
server if need be).

Thanks.

PS Don't send me e-mail, I don't have access to that account anymore.