Hello All:

  I am planning a conversion to ElevateDB from DBISAM v1 and am interested
in the bigger issues i will neew to address in my sourcecode. I noticed that
ElevateDB does not have physical rownumbers whereas DBISAM does - has this
been an issue for anybody ???

Thank you

Neil Huha
Profit Monster Data Systems

Neil


That's one hell of a jump and I never used V1 (I came in at V2).

A lot will depend on wether you use SQL much or not at present. If you don't your single biggest issues will be learning EDBManager and coming to terms with the catalog and the fact that you can no longer set a table's database to a path. The next major factor is wether you're jumping to unicode which mainly has implications on migration.

For me some of the biggest issues were:

NULL <> emptystring
Data is no longer RTRIM'd when posting
Queries are single statement rather than ; separated multistatement

If you use SQL much you have the joy of learning a whole new script language (very powerful) as well as new syntax for SQL itself. You also (probably) have the single quote/double quote issue that occurred between V3 & V4 (I think).

The conversion section of the manual has been much improved since its inception and gives some useful guidance.

If you have any specific questions post and we'll try and answer.

Roy Lambert [Team Elevate]

Neil,

<< I am planning a conversion to ElevateDB from DBISAM v1 and am interested
in the bigger issues i will neew to address in my sourcecode. I noticed that
ElevateDB does not have physical rownumbers whereas DBISAM does - has this
been an issue for anybody ??? >>

If you're referring to the logical row numbers (1..RecordCount), then yes,
you'll have to work around that by using your own numbering, and or just not
using a logical position/number in your application logic.  They're not
reliable except in cases where you know the underlying data will not change
at all, so they're really only useful in temporary tables or query result
sets.

How exactly are you using the logical row numbers in your application ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

  I am using recordcount alot to run a process on all records usually after
applying a filter

 If TBSalesman.RecordCount>0 Then
       Begin
         TBSalesman.First;
         Repeat
           do something
           TBSalesman.Next;
         Until (TBSalesman.Eof) or (Count>100);
       End;

I am using table.recno to update a few progressbars as follows:

InvReadProgressBar.Position:=Trunc((Datamodule1.TBInv.RecNo/Datamodule1.TBInv.RecordCount)*InvReadProgressBar.Max);

That is it - am looking forward to the powerful sql and database engine
features. I am preparing my final releases of the current product over the
next 45 days.

My estimate is that it will take me 90 days or so to migrate to the new
platform.

Neil








"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:7B30C0FC-EF03-485F-8051-555F00916D6C@news.elevatesoft.com...
> Neil,
>
> << I am planning a conversion to ElevateDB from DBISAM v1 and am
> interested in the bigger issues i will neew to address in my sourcecode. I
> noticed that ElevateDB does not have physical rownumbers whereas DBISAM
> does - has this been an issue for anybody ??? >>
>
> If you're referring to the logical row numbers (1..RecordCount), then yes,
> you'll have to work around that by using your own numbering, and or just
> not using a logical position/number in your application logic.  They're
> not reliable except in cases where you know the underlying data will not
> change at all, so they're really only useful in temporary tables or query
> result sets.
>
> How exactly are you using the logical row numbers in your application ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Neil

The first is easy to convert

> I am using recordcount alot to run a process on all records usually after
>applying a filter
>
> If TBSalesman.RecordCount>0 Then
> Begin
> TBSalesman.First;
> Repeat
> do something
> TBSalesman.Next;
> Until (TBSalesman.Eof) or (Count>100);
> End;

Use a TEDBQuery with RequestSensitive set to True along the lines of

SELECT * FROM TBSalesman RANGE 1 TO 100

then just a while not .eof loop

The second you'll need your own counter.

Roy Lambert [Team Elevate]

Roy,

<< Use a TEDBQuery with RequestSensitive set to True along the lines of

SELECT * FROM TBSalesman RANGE 1 TO 100

then just a while not .eof loop >>

The current EDB 2.03 B6 cannot return a sensitive result set with a RANGE
clause.  However, the good news is that the next B7 can.

--
Tim Young
Elevate Software
www.elevatesoft.com

Neil,

<< I am using recordcount alot to run a process on all records usually after
applying a filter >>

That's not a problem, RecordCount still works just fine.

<< I am using table.recno to update a few progressbars as follows:

InvReadProgressBar.Position:=Trunc((Datamodule1.TBInv.RecNo/Datamodule1.TBInv.RecordCount)*InvReadProgressBar.Max);>>That's a bit of a problem, and will require you to to count the currentposition yourself while looping through the rows.<< That is it - am looking forward to the powerful sql and database enginefeatures. I am preparing my final releases of the current product over thenext 45 days. My estimate is that it will take me 90 days or so to migrate to the newplatform. >>That's probably right on target, although coming from DBISAM 1.x may mean alot less work, mainly because DBISAM 1.x was fairly simple in terms of itsfeature set.--Tim YoungElevate Softwarewww.elevatesoft.com

Tim


My new profession is ...... mind reader

Roy Lambert

<<  "Tim Young [Elevate Software]" wrote:

"...The current EDB 2.03 B6 cannot return a sensitive result set with a RANGE
clause.  However, the good news is that the next B7 can.

--
Tim Young -------------------->>

Tim,

Technically speaking, since SQL has NO natural record order a programmer can rely on, most queries are going to need ORDER BY clause (with or without RANGE).
Using "ORDER BY" makes query INSENSITIVE though it may be "Selecting From" only one table and not using no calculated fields.

To get around this, I have been using two forms (or 2 tabs on a PageControl) and two queries. First shows a list of records in DBGrid from a query using anything I
need "SELECT X, Y, Z From ThisTable WHERE...ORDER BY..." etc which gives me an INSensitive query. User selects a record in DBGrid, clicks "Edit" button which
does a 2nd LIVE query using UniqueID field of record selected in the DBGrid.

(1) Any suggestion re: if there is a better way than the approach I am using ?

(2) Any plans/thinking that one table query with ORDER BY remains SENSIIVE. I assume there are good technical reason why this restriction exists. I am sure you will
at least think about it [Roy L: Please help convince Tim] .

Thanks for B7 "feature update."

JayM

JayM


Providing your ORDER BY clause is using existing indices then you should get a sensitive result if you've asked for one.

Roy Lambert [Team Elevate]