Mark,

<< Is your testing software homespun or commercial? If commercial, what
package? >>

I wrote it.  You can find the information on it here:

http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=13&msg=936&page=1#msg936

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< and a nice switch to say NULL and '' are the same would make it even
easier - for me at least >>

You can keep wishing on that one for now......

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


At last someone in this thread that understands a joke

Roy Lambert

Tim Young [Elevate Software] wrote:

> As for the data, the ElevateDB manager has a Migrate option for
> migrating DBISAM 4.x databases to a new ElevateDB database, and we
> include a unit (not part of the main engine) that you can use very
> easily in your applications for migrating the data.

Will I be able to easily convert DBISAM 2 tables to ElevateDB? While I
own licenses for all DBISAM versions I still have a large amount of
tables in DBISAM 2 format and I would really like to upgrade to
ElevateDB.

Jan Derk

Tim Young [Elevate Software] wrote:

> The biggest change that you can prepare for now is to switch any
> CreateTable, AlterTable, DeleteTable, RenameTable, OptimizeTable,
> RepairTable/VerifyTable, CreateIndex, DeleteIndex, DeleteAllIndexes method
> calls to using SQL instead.  We've done away with the dual-SQL-code mode for
> these types of operations, and all metadata management is done via SQL.
> Also, triggers, procedures, and functions are now SQL-based with the option
> of using native code (DLLs for Win32, and assemblies when the .NET version
> is ready) for functions only.
>

Wow! Big change. I wasn't expecting something this fundamental

My datamodules perform creation/verification on all my tables during
FormCreate. I've built them for years this way, beginning with 1.21. I
did it this way because the help showed this as an example and it was
elegant. I know how to do it using SQL, but building a SQL command
string is so in-elegant (and much more work) compared to
"wrkTable.FieldDefs.Add('wrkField',ftString,20,false)",
"wrkTable.VerifyTable",  "wrkTable.OptimizeTable",
"wrkTable.RepairTable", "wrkTable.AlterTable",
"wrkTable.IndexDefs.Add('','wrkField',[ixPrimary])" etc.

I like SQL as much as the next guy for querying and updating my data,
but for table maintenance (in my opinion) its a PITA. Is there a reason
for doing away with these methods? I know its late in the game and I've
probably missed your telling the group about this change before, but is
there any way to get you to change your mind and put code methods back
in? Pretty please?

Mark

Hannes Danzl[NDD] wrote:
....
>> That's brilliant - I didn't realise that update also altered all my
>> sql statements and delphi code
>
> Try COALESCE.

The point is that you have to find all places first. No help whatsoever, not
even an error message.

Ralf

Hello Mark,

> Wow! Big change. I wasn't expecting something this fundamental

I expect much more "surpizes" than he's currently telling to us.

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

>
>
> Wow! Big change. I wasn't expecting something this fundamental
>
>
>
> I like SQL as much as the next guy for querying and updating my data,
> but for table maintenance (in my opinion) its a PITA. Is there a reason
> for doing away with these methods? I know its late in the game and I've
> probably missed your telling the group about this change before, but is
> there any way to get you to change your mind and put code methods back
> in? Pretty please?
>
> Mark

I agree!

Mark A. Andrews wrote:
....
> My datamodules perform creation/verification on all my tables during
> FormCreate. I've built them for years this way, beginning with 1.21. I
> did it this way because the help showed this as an example and it was
> elegant. I know how to do it using SQL, but building a SQL command
> string is so in-elegant (and much more work) compared to
> "wrkTable.FieldDefs.Add('wrkField',ftString,20,false)",

I don't think that FieldDefs will be changed.

> "wrkTable.VerifyTable",  "wrkTable.OptimizeTable",
> "wrkTable.RepairTable", "wrkTable.AlterTable",
> "wrkTable.IndexDefs.Add('','wrkField',[ixPrimary])" etc.

I see no problem to write some functions that can emulate these calls. I'll
try to write some and put them on .binaries as soon as ElevateDB is out.

Ralf

Ralf Mimoun wrote:

>
> I see no problem to write some functions that can emulate these calls.
> I'll try to write some and put them on .binaries as soon as ElevateDB is
> out.
>

Actually, after I wrote my email, I thought about the same thing.
However, until we see the final product, it isn't much more than
thoughtware.

Also Tim, since EDB is changing so much, can DBISAM and EDB be installed
simultaneously? The thought of having to uninstall DBISAM, install EDB
and then having to port ALL my applications at one time is daunting. It
would be nice to be able to install EDB with DBISAM, play with it a
while and then port as necessary and when time permits.

Mark