Tim


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

Roy Lambert

> and a nice switch to say NULL and '' are the same would make it even easier -
> for me at least
Hm, this switch is called update statement and you could
adjust your values instantly:
update table xxx set fff = '' where fff is null
Then prohibit nulls and you will only have '', so nulls will no
longer bother you on text fields... If you don't need nulls use
NOT NULL - how simple is that?

Have mercy on Tim! Adding the switch you're asking for will make him
reply 1000 times to everybody, that "your spaces are converted to
nulls and/or you query doesn't work because you have the switch on".



Michael

Tim,

Is the migration of a DBISAM 4 (and/or 3) Delphiprogramm to an ElevateDB
programm as easy as from e.g. DBISAM 3 to 4 ?

Henri Maas



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:0BF578F0-F1C8-4E5A-AF3C-C85A4F5C4650@news.elevatesoft.com...
> Just a quick note to let everyone know the upcoming rollout sequence for
> ElevateDB.  There will be many incarnations of the product in terms of
> platforms, etc. so they won't all be available at the initial release.
> The rollout will go as follows:
>
> ElevateDB for VCL/Win32 (Delphi 5, 6, 7, C++Builder 5 and 6, and BDS 2005
> and 2006)
> ElevateDB for VCL/.NET (BDS 2005 and BDS 2006)
> ElevateDB for Kylix/Linux (Kylix 2 and 3)
>
> ElevateDB ODBC driver and ADO.NET data provider
>
> The lag time between rollouts shouldn't be very large, but we need to do
> it in this fashion to keep things manageable here.
>
> The products will be organized as follows:
>
> EDB-VCL*  (ElevateDB for VCL/Win32 and VCL/.NET)
> EDB-CLX*  (ElevateDB for Kylix/Linux)
> EDB-MDAC* (ElevateDB for Microsoft Data Access Components ODBC/ADO.NET)
>
> Also, as previously mentioned, the pricing will be as follows:
>
> For all version 4 STD and STD-SRC products to the equivalent version 5
> product:  $159
> For all version 4 CS and CS-SRC products to the equivalent version 5
> product:  $259
>
> For all version 3 STD and STD-SRC products to the equivalent version 5
> product:  $209
> For all version 3 CS and CS-SRC products to the equivalent version 5
> product:  $409
>
> However, previously it was mentioned that the ADO.NET data provider will
> be provided as a separate product like the ODBC products.  This has
> changed, and the ADO.NET data provider will be provided with the ODBC
> driver as the new EDB-MDAC line of products.
>
> Finally, I can't give a date yet for the actual release, but I will do so
> as soon as I can say it with 100% confidence in its accuracy.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Michael


>Hm, this switch is called update statement and you could
>adjust your values instantly:
>update table xxx set fff = '' where fff is null

That's brilliant - I didn't realise that update also altered all my sql statements and delphi code


Roy Lambert

Roy Lambert wrote:
....
>> Hm, this switch is called update statement and you could
>> adjust your values instantly:
>> update table xxx set fff = '' where fff is null
>
> That's brilliant - I didn't realise that update also altered all my
> sql statements and delphi code

The first step will be to set the default value of all char fields to '',
that should change the NULL fields. Then we have to search for NULL in .pas
and .DFM - and hope that there is no line break in the DFM somewhere in
"NULL". But I mut admit that I have a bad gut feeling about that NULL <> ''
thing. The quote and \MEMORY\ changes for version 4 where way easier: you'll
get an error message for all statements you did not change. That NULL field
handling will not cause any errors or warnings and are therefor the places
you can't change (semi-) automatically very hard to find.

Ralf

Tim Young [Elevate Software] wrote:

> Just as a heads-up, there may not be a beta, or if there is, it may be very
> brief and just for the purpose of allowing people to play around.  With our
> automated testing, we cando a lot of the testing here and be assured that
> ElevateDB meets a pretty high standard for quality.
>

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

Mark

Henri Maas wrote:

>
> Is the migration of a DBISAM 4 (and/or 3) Delphiprogramm to an ElevateDB
> programm as easy as from e.g. DBISAM 3 to 4 ?
>

My question as well... What, if any, conversion will be necessary? Is
there anything in 4 or 3 that will be a "gotcha" on conversion? Are
there any "pre-conversion" adjustments that we can be making now to ease
the transition?

Mark

Roy Lambert wrote:

> Michael
>
>
> > Hm, this switch is called update statement and you could
> > adjust your values instantly:
> > update table xxx set fff = '' where fff is null
>
> That's brilliant - I didn't realise that update also altered all my sql
> statements and delphi code

Try COALESCE.

--

Hannes Danzl
Newsgroup archive at http://www.tamaracka.com/search.htm

Henri,

<< Is the migration of a DBISAM 4 (and/or 3) Delphiprogramm to an ElevateDB
programm as easy as from e.g. DBISAM 3 to 4 ? >>

No.  There are a lot of things that are similar, but there are a lot of
things that are different also.  The SQL has changed a bit, and a lot more
is done now via SQL instead of in code.  Also, the naming conventions have
changed to reflect the fact that database names are now always identifiers,
and not paths.  For example, this DBISAM SQL:

SELECT * FROM "c:\temp\customers"

would now be

SELECT * FROM Temp.Customers

and you would be required to create the Temp database, of course, by using
this SQL:

CREATE DATABASE "Temp"
PATH 'c:\temp'
DESCRIPTION 'Temp Database'
MAX SESSION COUNT 4096

and then a CREATE TABLE statement to create the Customers table.

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.  It could also be adapted to just about any other
source database rather quickly also, but initially we'll only have support
for migrating DBISAM databases.

We'll have complete documentation in ElevateDB on what has changed and how
to migrate successfully from DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mark,

<< My question as well... What, if any, conversion will be necessary? Is
there anything in 4 or 3 that will be a "gotcha" on conversion? Are there
any "pre-conversion" adjustments that we can be making now to ease the
transition? >>

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.

--
Tim Young
Elevate Software
www.elevatesoft.com