Moving from Paradox to Interbase
Shane Sturgeon
Not sure if this is the right group, so please accept my apoligies in
advance if it isn't.
In his article on the future of the BDE
(http://bdn.borland.com/article/0,1410,28688,00.html), John Kaster said that
Borland reccommended migrating paradox tables to Interbase Desktop. I was
under the impression that in order to distribute interbase applications you
needed a deployment licence for interbase. Can anyone advise me as to either
what the licencing situation is when distributing a simple shareware app
that accesses a local database, or alternatively where I may be able to find
the answer? I have looked but are yet to find the answer.
Thanks in advance
Shane
Adam Hair
I've been down this path a little, and I'm under the impression of the
following:
Firstly, there is an open-source freeware version of Interbase. (Version
6.0) If you distribute this with your applications, you will not require
licensing from Borland. The downside to this is that Borland are not going
to continue any support for the Opensource version of interbase -so if you
want to stay with the latest, you require the 'Certified' version of
interbase - which of course requires a license.
I personally wouldn't choose (and have not chosen) interbase for local
databasing. Firstly - because of the licensing issues, but also secondly
because interbase is way so different to paradox.
There are freeware components out at the moment that will allow you to
access and save .db2 database files without using the BDE that may help.
Alternatively if you're looking for a more involved solution you may want to
try DBISam from elevatesoft. (DBISam costs for it's component suite, but all
applications and databases are royalty free).
I myself are currently figuring out what database I should merge to after 7
years development with Paradox tables (starting with good ol' Pdox3.5) and
are not taking anything lightly. I have played with interbase, and it is
good for what it does - but I am more used to local databases as opposed to
SQL transactions and DBISam is looking good for me at the moment.
Aparently the advantages of going with a freeware component or dbisam over
interbase are that you can deploy ONLY your .exe. (No need to deploy other
drivers, dll's, etc, etc), and also their are no royalty issues.
Of course I may be wrong about Interbase, but no one has corrected me yet if
I am. <g>
HTH
Adam.
"Shane Sturgeon" <shane.s...@stonebow.otago.ac.nz> wrote in message
news:3d659aed$1...@newsgroups.borland.com...
Shane Sturgeon
I have looked at DBISam in the past, but will take another look based on
your reccomendation.
During your investigations with Interbase, did you find out how to actually
connect to a local IB database without using the BDE? eg Is it possible to
simply create the interbase db file (gdb from memory) and hook a delphi app
into it, or do you need to continue to deploy the BDE with the app?
Regards
Shane
"Adam Hair" <ahair@ _remove_ netconnect.com.au> wrote in message
news:3d65becc$1...@newsgroups.borland.com...
Olivier Beltrami
> your reccomendation.
If you are "happy" witht the Paradox architecture (local) then DbiSAM is
great; feels right at home, easy to convert to, and great support.
Olivier
Adam Hair
> I have looked at DBISam in the past, but will take another look based on
> your reccomendation.
At this stage I haven't purchased DBISam yet. I'm not one to rush into
things and are weighing up all options at present. I've downloaded a demo
version of DBISam and have started mergine one of my larger apps from
Paradox to DBISam and I must admit it's going quite well.
I'd suggest checking out the demo. I've three reasons for holding off
purchasing it:
1)
I might as well convert my entire application and make sure it works using
the demo components first before I spend any cash just incase if their's any
surprises. (So far - so good). I must admit - the ability to test before
buying is a great initiative from elevatesoft!
2)
While I'm converting, it still gives me time to weigh up any other options
that may exist. (But still, so far DBISam looks the best for me)
3) And of course, their's talk about DBISam v4 being released. I might as
well wait until it's released instead of buying 3 now, and in 4 months time
having to coff up extra $'s for an upgrade. :-)
> During your investigations with Interbase, did you find out how to
actually
> connect to a local IB database without using the BDE? eg Is it possible to
> simply create the interbase db file (gdb from memory) and hook a delphi
app
> into it, or do you need to continue to deploy the BDE with the app?
Yes! It is possible to completely do without the BDE. (That's the whole idea
of interbase) I'm not sure which versions of delphi have the components.
(I've currently got D6 enterprise), but AFAIK there are two different ways
to bypass the BDE:
1) Use the interbase components in delphi. (TIBDatabase, TIBTable, TIBQuery
etc, etc). This links directly to the Interbase Server and works quite well.
2) Use DBExpress with an Interbase SQL Driver. (Never tried it personally)
Again Hope This Helps
Adam.
Andrew Skinner
server. Look at the D7 feature matrix before you buy. Have you
considered going to ADO, as there are ole-db drivers for many databases
and it SEEMS to make swapping easier at a leter date?
MS say this is the way forward for desktop databases.
I'm in a similar quandry, except I'm waiting for D7 to drop through the
letter box...
Andrew
Bill Artemik
have a "large" application that uses many tables and has more than a
couple of simultaneous users you will see a HUGE benefit from using a
SQL server in place of local (ie. Paradox, DBase, Access) tables.
If you have any thoughts of larger scale application building it would
be DEFINITELY worth your while to come to know at least one of these
SQL engines.
Most of my past work was with Paradox and DBase tables. When our
project grew to a size that caused local engines to bog down we began
looking at the SQL world. Admittedly it was a struggle at first,
primarily due to our mindset (not much different from our Paradox 3.5
to Delphi 2 mindset, either, though, and we were [eventually] VERY
happy we made that decision!)
In the defence of what you know, you have little learning curve. But
you are also limited to what you can do and there are a bunch of other
issues you must deal with in regards to table data access, security,
corruptability, etc. With a SQL engine handling all of this for you
most of those headaches go away. AND the world opens up for you. Yes,
as a result you have to learn new tricks but they are migratable
tricks. ie. What works on Interbase will work with MYSQL or Oracle or
MSSQL server (there might be some syntactical changes but the
capabilities exist.)
I'm not recommending one over the other as I don't know your
situation. I just know if you have the need to scale your applications
and decide to take the time to learn how to effectively use a SQL
engine for your data access you will not regret it.
Some SQL engines I've looked at:
MSSQL server (naturally...as many of our clients use this already) I
recently discovered a decent set of native Delphi components for
direct access to MS SQL Server engine. Very strong and very fast! You
may find that many larger clients you write for already use MSSql
Server so that means YOU don't have to do any of the backend work
other than providing the table schema.
MYSQL - looked and played with an older version. Now it's better than
before and still free. Good Delphi component sets avaialable, too.
Easy to find on the internet.
InterBase - Can't consider the switch from local to SQL Server without
looking at Interbase and it (in version 6.0 anyway) was free and very
fast! Also has a good Delphi component set available to directly
access the Interbase Server engine. I've heard rumors that it can bog
down with large datasets (something about memory caching, if I recall
correctly. Can't confirm this but worth noting if you've got 30mb +
size tables to deal with.)
Advantage - Local table centric but allows very good speed with
multiple user access. Their server engine is quick and povides
effecient network access to data. Queries are very fast, too. Not as
strong with the SQL language as most dedicated SQL servers and slow to
save result query data sets to files (e.g. you want to save a paradox
query to a file) (although upcoming version 6.2 is suppose to improve
some of these shortfalls)
For reporting (static queries and not too complex SQL statements) I
still like the bde on local tables (Kudos, borland, for making this
mysteriously fast) but more flexibility and speed is needed for larger
scale applications (more than, say, 5 simultaneous users).and
SQLServers seem to (in my experience) scream on a good server. And I
have to admit...I like the fact that all the SQL query work happens on
a machine OTHER than the client pc (Network admin. will like you for
this, too! Doing a query against a 50meg table on a fat-client system
slows the network traffic significantly.)
There are many good books and outstanding support right here (in the
Borland newsgroups under SQLServer) for newbies to get going in db
server development. If it's something you even THINK you want to
explore, go for it. You'll be surprised at what you'll learn!
HTH.
Bill
----------------------
Bill Artemik
Software Engineer
Droste Consultants, Inc.
bi...@droste1.com
"He who procrastinates
Adam Hair
Thanks very much for your detailed input. I found this very interesting and
informative.
I must admit that I was looking at SQL because of it's speed and especially
because the work was done on the server side, and not the client side. The
main problem that I hit was the fact that I already had an application
that's been 18 months in the working on paradox tables, and it seemed like
too much work (without completely re-writing the app) to convert to SQL.
I found with DBISam though, they do have a client<>server option that only
seems to require a few property changes on their TDatabase and all SQL work
is done on a server instead of locally. To me, this seemed like the logical
option, because converting from pdox to dbisam so far has been easy.
Although I do admit that I came close to SQL, and would have come closer to
a comparison between dbisam and SQL if I had a little time on my hands for
the learning curve <g>, was starting on an application, instead of 18 months
through it and of course, if Interbase looked like it was going to continue
to be free. (Of course, I suppose I should have a look at mysql :-)
Have a good weekend.
Adam.
Brian Bushay TeamB
>During your investigations with Interbase, did you find out how to actually
>connect to a local IB database without using the BDE? eg Is it possible to
>simply create the interbase db file (gdb from memory) and hook a delphi app
>into it, or do you need to continue to deploy the BDE with the app?
DBExpress and Intebase Express are the two options that come with delphi for
components to directly use Interbase without BDE.
Interbase Express components work only with Interbase. They are probably the
best option if you only need to develop in interbase.
DbExpress components have drivers for most of the SQL servers and is the
component you want to choose if you need to develop for more than one database.
--
Brian Bushay (TeamB)
Bbu...@NMPLS.com