Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Future Considerations
Tue, Sep 25 2007 3:27 PMPermanent Link

Stuart Kelly
Hi all,

We currently deploy all our software using DBISAM 3.30, obviously we need to consider
migrating.

There are a number of choices to consider with various costs, financial and time.

* DBISAM 4
--- We have a licence but ElevateDB is the future direction.
--- Migration time

* ElevateDB
--- Cost
--- Migration time

* MySQL
--- Deployment costs.
--- Migration time
--- Unfamiliar database

* PostgreSQL
--- Free database
--- Migration time
--- Unfamiliar database

* Blackfish
--- Included with RAD Studio 2007
--- Migration time
--- Unfamiliar database

I'm not sure which way to go, supporting multiple databases is complicated, unless you use
ODBC/DB Express?

Kind regards, Stu
Tue, Sep 25 2007 3:46 PMPermanent Link

"Donat Hebert \(Worldsoft\)"
I'll just comment on what I'm familiar with / our experiences only.

Suggestion:
1) To DBISAM 4 is easiest migration by far.  With a bit of planning, good
GSR tool (search/replace) you can usually accomplish most in one day.
   Consider library for standard pathing functions if you haven't already
done so.  This way, you can reprogram for ElevateDB by changing
   the library call versus numerous line changes.   See migration notes in
manual and on these newsgroups. (ie Ansiquotes pathing )
   Version 4 is more stable, faster than 3.30 .. large return for little
investment.

Lots of work:
2) MySQL.  We seriously look at this a while back but heavy effort required
as we are using many DBISAM specific calls despite
using Asta server  Bottom line however, our customers indicated they were
happy with DBISAM's simple support and implementation.
They did NOT want to change.

At a later date, you could consider ElevateDB but need good migration
planning as its still a Database approach but easier by far
than entertaining another.  There are a number of features that will force
you to rewrite more code, depending on what you have
taken advantage of so far in DBISAM.  (ie Update statements that update many
fields, scripts etc. etc.)

There are quite a few things we take for granted coming from DBISAM as life
is simple here, and we get a lot of functionality.

My 2c.    hth.  Donat.


"Stuart Kelly" <stuart@nospam.com> wrote in message
news:06A125A5-4E85-4880-B71B-5DE658E2FBCB@news.elevatesoft.com...
> Hi all,
>
> We currently deploy all our software using DBISAM 3.30, obviously we need
> to consider
> migrating.
>
> There are a number of choices to consider with various costs, financial
> and time.
>
> * DBISAM 4
> --- We have a licence but ElevateDB is the future direction.
> --- Migration time
>
> * ElevateDB
> --- Cost
> --- Migration time
>
> * MySQL
> --- Deployment costs.
> --- Migration time
> --- Unfamiliar database
>
> * PostgreSQL
> --- Free database
> --- Migration time
> --- Unfamiliar database
>
> * Blackfish
> --- Included with RAD Studio 2007
> --- Migration time
> --- Unfamiliar database
>
> I'm not sure which way to go, supporting multiple databases is
> complicated, unless you use
> ODBC/DB Express?
>
> Kind regards, Stu
>

Wed, Sep 26 2007 1:57 PMPermanent Link

Stuart Kelly
Hi Donat,

Thanks for your feedback.  The simplest route is DBISAM 4 but I would like other peoples
opinions.

>
> Consider library for standard pathing functions if you haven't already done so.  
> This way, you can reprogram for ElevateDB by changing the library call versus
> numerous line changes.  
>

I didn't write the original code, so will do this part first, but have a few questions.

1) Would you use a data module for this or just a source file?
2) Should I define thinks like queries or can I just return TDataset from functions?

#define GDBQuery TDBISAMQuery
#define GDBTable TDBISAMTable

GDBQuery *GetQuery(AnsiString SQL, GDBQuery *Query);
GDBTable *OpenTable(AnsiString TableName);

vs

TDataSet *GetQuery();

Thanks Stu
Wed, Sep 26 2007 3:14 PMPermanent Link

Add support costs too, particularly if you are not in control of the
machines. MS SQL server was a nightmare for us when we'd be asked to
install our software on a PC that already had it, but they'd lost the
admin password and SQL server password, and didn't have enough space on C
for a side-by-side install so had to work out how to get another on D. And
then when the database got full, it would take a few hours to empty the
table to make it work again.

DBISAM was used to replace that, and hasn't had any hassle since.

/Matthew Jones/
Thu, Sep 27 2007 10:50 AMPermanent Link

"Donat Hebert \(Worldsoft\)"
1) We only store sql queries within a component if they are static ie only
'talk to one db source
2) The database property already handles
3) The mixed sources are coded in source like
....
Sql.Clear;
Sql.add(' Select .. ')
Sql.add(' From ' +CAlias('NewReleases','Tablename') + ' M');
Sql.add(' Join ' +CAlias('OtherDB',Table2') + ' T2 '); etc...
....

The function CAlias (Convert alias) is stored in a simple Source file used
by all forms and Dm
(Could certainly be in a Dm depending if all your forms use the dm already )

So the CAlias Function can return the ansiquoted or dbo format or whatever.

Function(CAlias(V_Alias,V_Filename:String): String;

You could even code with 'Engine' Variable like (D)Bisam or (E)levate so one
returns ansiqutoed
and the other use the databasename syntax ..  If syntax changes, one change
fixed all.

There are probably better ways but this works.  hth.
Donat.


> 1) Would you use a data module for this or just a source file?
> 2) Should I define thinks like queries or can I just return TDataset from
> functions?
>
> #define GDBQuery TDBISAMQuery
> #define GDBTable TDBISAMTable
>
> GDBQuery *GetQuery(AnsiString SQL, GDBQuery *Query);
> GDBTable *OpenTable(AnsiString TableName);
>
> vs
>
> TDataSet *GetQuery();
>
> Thanks Stu
>

Fri, Sep 28 2007 12:49 AMPermanent Link

Dave Harrison
Stuart Kelly wrote:
> Hi all,
>
> We currently deploy all our software using DBISAM 3.30, obviously we need to consider
> migrating.
>
> There are a number of choices to consider with various costs, financial and time.
>
>  * DBISAM 4
>  --- We have a licence but ElevateDB is the future direction.
>  --- Migration time

Works fine for a million rows of data. Fulltext search is a breeze to use.

>
>  * ElevateDB
>  --- Cost
>  --- Migration time

You'll need to list the cost benefits to determine if it is worth
switching. It's suppose to be faster but I still need to confirm that.

>
>  * MySQL
>  --- Deployment costs.
>  --- Migration time
>  --- Unfamiliar database

Harder to install and using InnoDb for transactions is a bit of a pain.
MySQL is more of an enterprise database and will be able to store more
data than any Delphi database I've encountered. If your data is hundreds
of gb's or even terabytes, then MySQL is the only solution apart from
Oracle or SQL Server. Cost is $595/server.

>  * PostgreSQL
>  --- Free database
>  --- Migration time
>  --- Unfamiliar database

Works much better on Linux than on Windows. Not as fast as MySQL but
more robust.

>
>  * Blackfish
>  --- Included with RAD Studio 2007
>  --- Migration time
>  --- Unfamiliar database

I believe there are substantial royalites involved with Blackfish.

>
> I'm not sure which way to go, supporting multiple databases is complicated, unless you use
> ODBC/DB Express?

There is also Firebird which is free and well supported.


Dave
Image