Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 6 of 6 total |
Future Considerations |
Tue, Sep 25 2007 3:27 PM | Permanent 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 PM | Permanent 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 PM | Permanent 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 PM | Permanent 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 AM | Permanent 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 AM | Permanent 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 |
This web page was last updated on Thursday, March 28, 2024 at 08:36 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |