Board index » delphi » Migrating out of Paradox tables

Migrating out of Paradox tables

Hi,

I was wondering if I could get input/concensus on the following issues.

Baseline:
1. Our data is stored in Paradox tables. Currently about 800MB of data, most
of which was generated in the last 2 years.
2. There are other ideas comming forwards which means that the data growth
will increase.
3. There are about 30 tables involved, 15 Delphi apps.
4. We have and will continue to use Delphi, upto 5 now.
5. Apps are not written in SQL'able fashion due to Paradox history (from
version 3.5). Infact I dropped SQL back in Delphi 1 times cos it was soooo
slow then.

Questions:
1. Should we migrate to an SQL server? If so, economy and ease of migration
is crucial.
2. Should we move to Dbase tables, given that these are pretty well public
domain now?
3. Should we roll our own? If it takes 12mths to move across , should we
perhaps look at customizing our data. It is not for public consumption
anyhow.

Outcomes:
1. Ease of maintenace and availability of cheap tools.

I'm at the dithering/spinning wheels stage and dont know which way to jump.

Thanks for any input.

Jim

 

Re:Migrating out of Paradox tables


1) For heavy multi-user database systems an SQL server is always better (but
not faster). If you want a cheap SQL database I suggest Interbase 6 (it is
free).
2) No, Paradox is better than dBase in multi-user environments.
3) Thanks to the BDE, switching to another database type doesn't take a lot
of time. You can use Datapump (from Delphi Enterprise) to move your data to
the SQL server and take a few weeks to test and adapt the existing
applications.

"Jim Eadie" <jim_eadie@[take this out]mimotopes.com> schreef in bericht
news:3jeans0a2u2uskei6fovrl824lgesabe9k@4ax.com...

Quote
> Hi,

> I was wondering if I could get input/concensus on the following issues.

> Baseline:
> 1. Our data is stored in Paradox tables. Currently about 800MB of data,
most
> of which was generated in the last 2 years.
> 2. There are other ideas comming forwards which means that the data growth
> will increase.
> 3. There are about 30 tables involved, 15 Delphi apps.
> 4. We have and will continue to use Delphi, upto 5 now.
> 5. Apps are not written in SQL'able fashion due to Paradox history (from
> version 3.5). Infact I dropped SQL back in Delphi 1 times cos it was soooo
> slow then.

> Questions:
> 1. Should we migrate to an SQL server? If so, economy and ease of
migration
> is crucial.
> 2. Should we move to Dbase tables, given that these are pretty well public
> domain now?
> 3. Should we roll our own? If it takes 12mths to move across , should we
> perhaps look at customizing our data. It is not for public consumption
> anyhow.

> Outcomes:
> 1. Ease of maintenace and availability of cheap tools.

> I'm at the dithering/spinning wheels stage and dont know which way to
jump.

> Thanks for any input.

> Jim

Re:Migrating out of Paradox tables


Jim, you don't indicate the reason you are considering a change in the first
place. Running out of things to do?  :-)

IMO, both the BDE and Paradox are rather poor solutions. If you want to stay
with a desktop database, you should look into DBISAM, an excellent product
that we use quite a bit. It has conversion utilities for your tables, You
can download a trial version and see how it goes. If you want to go to an
SQL server, it's hard to go wrong, most are excellent products - Advantage,
Interbase, and of course the biggies. Advantage might be an interesting
alternative for you, since I think it supports the "ttable model" better
than most, while still allowing for migration to SQL.

Robert

Jim Eadie <jim_eadie@[take this out]mimotopes.com> wrote in message
news:3jeans0a2u2uskei6fovrl824lgesabe9k@4ax.com...

Quote
> Hi,

> I was wondering if I could get input/concensus on the following issues.

> Baseline:
> 1. Our data is stored in Paradox tables. Currently about 800MB of data,
most
> of which was generated in the last 2 years.
> 2. There are other ideas comming forwards which means that the data growth
> will increase.
> 3. There are about 30 tables involved, 15 Delphi apps.
> 4. We have and will continue to use Delphi, upto 5 now.
> 5. Apps are not written in SQL'able fashion due to Paradox history (from
> version 3.5). Infact I dropped SQL back in Delphi 1 times cos it was soooo
> slow then.

> Questions:
> 1. Should we migrate to an SQL server? If so, economy and ease of
migration
> is crucial.
> 2. Should we move to Dbase tables, given that these are pretty well public
> domain now?
> 3. Should we roll our own? If it takes 12mths to move across , should we
> perhaps look at customizing our data. It is not for public consumption
> anyhow.

> Outcomes:
> 1. Ease of maintenace and availability of cheap tools.

> I'm at the dithering/spinning wheels stage and dont know which way to
jump.

> Thanks for any input.

> Jim

Re:Migrating out of Paradox tables


I would like to know why you think Paradox/BDE is a
poor solution?  I am developing an app with about 20 tables.

Quote
PINKO <PI...@VATICAN.CURIA.GOV> wrote in message

news:Hksd5.163$8J2.1048674@dca1-nnrp1.news.digex.net...
Quote
> Jim, you don't indicate the reason you are considering a change in the
first
> place. Running out of things to do?  :-)

> IMO, both the BDE and Paradox are rather poor solutions. If you want to
stay
> with a desktop database, you should look into DBISAM, an excellent product
> that we use quite a bit. It has conversion utilities for your tables, You
> can download a trial version and see how it goes. If you want to go to an
> SQL server, it's hard to go wrong, most are excellent products -
Advantage,
> Interbase, and of course the biggies. Advantage might be an interesting
> alternative for you, since I think it supports the "ttable model" better
> than most, while still allowing for migration to SQL.

> Robert

> Jim Eadie <jim_eadie@[take this out]mimotopes.com> wrote in message
> news:3jeans0a2u2uskei6fovrl824lgesabe9k@4ax.com...
> > Hi,

> > I was wondering if I could get input/concensus on the following issues.

> > Baseline:
> > 1. Our data is stored in Paradox tables. Currently about 800MB of data,
> most
> > of which was generated in the last 2 years.
> > 2. There are other ideas comming forwards which means that the data
growth
> > will increase.
> > 3. There are about 30 tables involved, 15 Delphi apps.
> > 4. We have and will continue to use Delphi, upto 5 now.
> > 5. Apps are not written in SQL'able fashion due to Paradox history (from
> > version 3.5). Infact I dropped SQL back in Delphi 1 times cos it was
soooo
> > slow then.

> > Questions:
> > 1. Should we migrate to an SQL server? If so, economy and ease of
> migration
> > is crucial.
> > 2. Should we move to Dbase tables, given that these are pretty well
public
> > domain now?
> > 3. Should we roll our own? If it takes 12mths to move across , should we
> > perhaps look at customizing our data. It is not for public consumption
> > anyhow.

> > Outcomes:
> > 1. Ease of maintenace and availability of cheap tools.

> > I'm at the dithering/spinning wheels stage and dont know which way to
> jump.

> > Thanks for any input.

> > Jim

Re:Migrating out of Paradox tables


Jim, you are actually on the cusp of the decision between "fileserver"
technology and "client/server" technology.  You are faced with this
decision because of a KNOWN BUG in the Windows 9x file-cacheing software
(VREDIR.VXD on the client, Opportunistic Locking on the server), both of
which are discussed at length on Corel's, Borland's, and Microsoft's own
support sites.  Both of which have definite solutions.  We have one
long-standing client who has been running Paradox tables on an NT/98
network for TWO YEARS without ONE incident of table corruption -- with
30+ logged-on users every single day.

"Transactions," that is to say, whether they're supported and how they
are supported, have nothing at all to do with reliability.  

Likewise, the future data-types that are supported (and I hasten to
point out that video, graphics, and so forth are all treated as "blobs"
or as "OLE fields" by databases today .. including Paradox) have no
bearing on your argument.

Jim, you're stuck on the wrong side of a classic FUD argument:  Fear,
Uncertainty, and Doubt.  This classic salesman's-strategy can lead you
to "buy absolutely anything to solve a problem you can't even describe"
... unless and until you can get your own handle on it.  What is the
source of your nervousness?  What will "a solution to that nervousness"
actually consist of and why?  Analyze it - understand it - solve it.

Quote
>Jim Eadie wrote:

> Thanks to you who replied, via email as well.

> My reasons for placing this message in the first place was not so much that
> Paradox tables are a problem in themselves, but that problems do arise in
> their usage. We are a WinNT 4 business and we regularly get indices out of
> date, bad val files , etc, which can be traced back to BDE and Network
> problems ( not BDE alone, or Network alone , but together). I guess
> transaction processing would clear up all of our problems, but this sort of
> processing is not easily done for Pdox tables.

> Also as Borland has stopped development on the BDE we think it might be
> worth thinking about the next 10 yrs of data and datatypes. For example, how
> long until voice becomes a datatype, video, graphics (moving and still),
> etc. I think this is something that XML is trying to forsee and address.

Re:Migrating out of Paradox tables


Thanks to you who replied, via email as well.

My reasons for placing this message in the first place was not so much that
Paradox tables are a problem in themselves, but that problems do arise in
their usage. We are a WinNT 4 business and we regularly get indices out of
date, bad val files , etc, which can be traced back to BDE and Network
problems ( not BDE alone, or Network alone , but together). I guess
transaction processing would clear up all of our problems, but this sort of
processing is not easily done for Pdox tables.

Also as Borland has stopped development on the BDE we think it might be
worth thinking about the next 10 yrs of data and datatypes. For example, how
long until voice becomes a datatype, video, graphics (moving and still),
etc. I think this is something that XML is trying to forsee and address.

Jim

Re:Migrating out of Paradox tables


Quote
Karen Whitlow <klwhi...@ncsu.edu> wrote in message

news:8lk721$8k4$1@uni00nw.unity.ncsu.edu...

Quote
> I would like to know why you think Paradox/BDE is a
> poor solution?  I am developing an app with about 20 tables.

BDE is all things to all people, and almost by definition that will tend to
be the lowest common denominator. Also bulky, subject to other folks
installing on top of your install, etc. I never used Paradox in production
work, but I see in this group enough folks pulling their hair to know I'd
rather not mess with it. There's even somebody who advertises "repair tools"
for Paradox, must be really bad to allow somebody to make a living repairing
Pdx files.

There's all kind of alternatives, at all price ranges. With excellent tools
like DBISAM or M$Access, and even better server based systems (you name it,
from Interbase to Advantage to the biggies), and Delphi interfaces (TTable,
TQuery and TDB) tailored to whichever database you've selected, I certainly
see no reason to buy into the installation and support headaches that seem
to come with BDE and Paradox, or to add the additional layer of processing.

Re:Migrating out of Paradox tables


Quote
Jim Eadie wrote:

...
> We are a WinNT 4 business and we regularly get indices out of
> date, bad val files , etc, which can be traced back to BDE and Network
> problems ( not BDE alone, or Network alone , but together).

That could (probably) be fixed by reading all tech. support info you
can find, developing the fix, putting it into all the programs and then
testing said programs to make sure the fix didn't break anything. Or
you can buy an SQL server and port your programs to that; you still
have to do the testing. It's kinda hard to do accurate cost-benefit
analysis without actually doing -- say, 75% of -- the work.

Quote
> Also as Borland has stopped development on the BDE we think it might be
> worth thinking about the next 10 yrs of data and datatypes. For example, how
> long until voice becomes a datatype, video, graphics (moving and still),
> etc.

That's not a concern as long as you're using standard data types.
I had problems with n*char types in MS SQL 7 and I had problems with
OLE fields in FoxPro. What matters is they aren't standard char/blob
types, not that they're server/desktop db tables.

IMO SQL server is a Good Thing (tm) because
you can do some of the processing on the server machine (less load
 on workstations)
you can reduce network traffic: with desktop db BDE would typically
 fetch the whole table and then do filtering; server will run the
 query/view/stored procedure and return the result only
you can implement some of your business rules as triggers & ref.
 integrity rules, making your client apps leaner. The flip side is
 that your business rules are now stored in 2 different places
most SQL servers have replication & clustering so you can have some
 redundancy there. I dunno if switching to a backup server is any
 easier/faster than remapping drives to where you have backup of
 your desktop DB.

Of course you could also go multi-tier and write a dcom/corba
server. That's single point of access for your db so you can do
transaction control there. You can also have all your business rules
there...

HTH
Dima
--
Mirrors and {*word*98} are abominable
because thay multiply entities.
        -- J. L. Borjes
-------------------------------------
BoomTime, 61 Confusion 3166, 150:2:1 (1)

Re:Migrating out of Paradox tables


Client/server architecture is powerful and useful for many applications
especially those with high user-counts or unreliable connections . . .
but it is NOT anyone's panacea.  There are license fees, installation
and connection issues, a startling amount of client-side software, and
many other things that can catch a fileserver-programmer by surprise.

Quote
>Dima Maziuk wrote:
> Of course you could also go multi-tier and write a dcom/corba
> server. That's single point of access for your db so you can do
> transaction control there. You can also have all your business rules
> there...

------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)
Quote
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep

Re:Migrating out of Paradox tables


Quote
Sundial Services <i...@sundialservices.com> wrote:
>but it is NOT anyone's panacea.  There are license fees,
installation
>and connection issues

Not with Interbase! (www.interbase.com). I'm in the process of
converting a Paradox system to Interbase, and it's going well.
IB6 itself is very reliable (even the beta). But the public
domain interface (IBX) is a bit dodgy. It's in a state of
contining development, and sometimes quite obvious bugs are left
in.

IBX is good because it's small, free, and fits in nicely with
the existing components. *If* you're prepared to put up with the
iffy bits. The other alternative is www.ibobjects.com, which is
bigger, more complex, costs money (usually), but also *works*!

I think the BDE is more-or-less dead. As are single-tier
database systems. Just look at the Kylix (?) stuff Borland are
putting out. It isn't even going to support dbase / Paradox.

John

-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Re:Migrating out of Paradox tables


Quote
John Sparrow wrote:

> Sundial Services <i...@sundialservices.com> wrote:
> >but it is NOT anyone's panacea.  There are license fees,
> installation
> >and connection issues

> Not with Interbase! (www.interbase.com). I'm in the process of
> converting a Paradox system to Interbase, and it's going well.

...

Quote
> I think the BDE is more-or-less dead. As are single-tier
> database systems.

Depends on your app. I'm now working on a single-user read-only
proggie and DB server is clearly not the right backend for that.
(My only problem with BDE/Pdox is that they have to run setup for
BDE alias, so I'll look into DBISAM). In a multi-user enviroment
client-server is definitely the way to go, sure, but not all apps.
are multi-user.

Dima
--
I like cats too. Let's exchange recipes.
----------------------------------------
Pungenday, 62 Confusion 3166, 41:2:2 (1)

Re:Migrating out of Paradox tables


Quote
John Sparrow wrote:

> Not with Interbase! (www.interbase.com). I'm in the process of
> converting a Paradox system to Interbase, and it's going well.
> IB6 itself is very reliable (even the beta).

I'm confident that Interbase as a true C/S will be a good choice
for 5..300 user installations. But how about that 1..4 user cathegory,
does anyone have experience in there?

With BDE/Paradox you can start with single W95/98 workstation only,
and BDE being a fast creature, the single user app runs very fast in
there. You can later add second W9x workstation, and make it a cheap
two user net.
BDE allows easily add 3..4 more W95/NT workstations, and run it
as a relatively simple, non-complicated, Peer to Peer network.

Someone claimed IB 6.0 Server process would never run happily under
W95/98, but usually needs NT. At least, if you want to have a 2 user
net, you'll need an extra dedicated NT server, and NT server licences,
only to serve those two W9x workstations.

Or has someone succeed to run IB 6.0 also on mini networks, like
two W9x workstations only, and with good response times? As a simple
Peer to Peer network?

Markku Nevalainen

Re:Migrating out of Paradox tables


Quote
Markku Nevalainen <m...@iki.fi> wrote in message news:3980C3DB.5B19@iki.fi...

> I'm confident that Interbase as a true C/S will be a good choice
> for 5..300 user installations. But how about that 1..4 user cathegory,
> does anyone have experience in there?

DBISAM. Links into your EXE, no special network files or such nonsense (uses
only the OS to control concurrency), you decide where to keep the table
location information (registry, INI, hardcode into the tdatabase, whatever),
fast, superb support, (almost) full SQL, a neat implementation of inmemory
table, queries can be saved to inmemory tables and used as input to other
queries, on and on. Have not had an opportunity so far to test the table
repair :-), but I'm sure it works. Very good product.

Re:Migrating out of Paradox tables


Quote
Dima Maziuk wrote:
>>...
> Depends on your app. I'm now working on a single-user read-only
> proggie and DB server is clearly not the right backend for that.
> (My only problem with BDE/Pdox is that they have to run setup for
> BDE alias, so I'll look into DBISAM).

You can easily create the alias for a Paradox database at runtime.  It
isn't much more than putting in a path=... in the parameters (keep the
path in a registry setting or an ini file).  I hardly ever put in an
alias in the BDE Admin program.

Btw - using IB + IBO is even better.

Aage J.

Re:Migrating out of Paradox tables


Quote
PINKO wrote:

> Markku Nevalainen <m...@iki.fi> wrote in message news:3980C3DB.5B19@iki.fi...

> DBISAM. Links into your EXE, no special network files or such nonsense (uses

Yes, I know DBISAM. It's great replacement for BDE, but it's not C/S engine
as Interbase. There should be also some kind of DBISAM C/S version coming, but
schedules for that are not very clear to me.

I would like to hear if someone has tested IB 6.0 to easily handle also those
small W9x installations.
Then I should not start considering DBISAM for tiny installations, and IB for
bigger ones. That would save a lot of writing the same code twice.

Markku Nevalainen

Go to page: [1] [2]

Other Threads