Tim

Date, time, and timestamp formatting routines that worked fine wth EBIsam 4.x do not work with ElevateDB 1.x.

with DBIsam I used the following formatting routines which works fine for DBIsam:

function FmtDteTimeParams(aDate: TDateTime): string;
begin
 result := #39 + Engine.DateTimeToAnsiStr(aDate, False) + #39;
end;

function FmtDteParams(aDate: TDateTime): string;
begin
 result := #39 + Engine.DateToAnsiStr(aDate) + #39;
end;

function FmtTmeParams(aTime: TDateTime): string;
begin
 result := #39 + Engine.TimeToAnsiStr(aTime, False) + #39;
end;


I had to change them for ElevateDB to the following:

function FmtDteTimeParams(aDate: TDateTime): string;
begin
 result := #39 + Engine.DateTimeToSQLStr(aDate, False) + #39;
end;

function FmtDteParams(aDate: TDateTime): string;
begin
result := #39 + Engine.DateToSQLStr(aDate) + #39;
end;

function FmtTmeParams(aTime: TDateTime): string;
begin
 result := #39 + Engine.TimeToSQLStr(aTime, False) + #39;
end;

But they do not work.  I get the following ElevateDB error #700: Expected Timestamp expression but instead found '2007-03-02 12:00 AM'.  Is there something else I need to
do.  What am I missing?  I looked through the on-line manuals, etc and I did not see anything related to date differences between the two products.

I just converted my entire app from DBIsam to ElevateDB and now it will not run because of the error (It ran just fine with DBIsam).  As part of starting the app, a query using
timestamps is returning some aggregate data to display on a Dashboard for the user.

Tom

Tom,

<< Date, time, and timestamp formatting routines that worked fine wth EBIsam
4.x do not work with ElevateDB 1.x. >>

For some reason, the DATE/TIME/TIMESTAMP literal changes didn't make it into
the migration guide as they should have.  It's been updated now:

http://www.elevatesoft.com/edb1migrate_types.htm

They need to be specified as:

DATE '<Literal>'
TIME '<Literal>'
TIMESTAMP '<Literal>'

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

That did the trick.  It now works exactly as I expect.  

Thankfully, I long ago abstracted the date, time, and timestamp formatting to a couple of routines so the changes were minor.

Thanks,

Tom

Tom,

<< Thankfully, I long ago abstracted the date, time, and timestamp
formatting to a couple of routines so the changes were minor. >>

Smart move.

We should have made DBISAM 3 and 4 use the standard prefixed constants, but
frankly, I simply missed it when we were doing those versions.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I didn't know that guide existed


"Also, VARCHAR columns no longer right-trim any spaces from strings that are stored in them. The string values are stored as-is"

Why. That's a nightmare scenario at least for me. I have no idea how many of my fields rely on the engine right trimming and now I have to manually trim them all?

I don't know (don't really care) if that's standard SQL. If you need to stick with it can we have an extension back to the old behaviour. PLEASE and quickly?

Roy Lambert

Roy,

<< Why. That's a nightmare scenario at least for me. I have no idea how many
of my fields rely on the engine right trimming and now I have to manually
trim them all? >>

If that's what you want, yes.

<< I don't know (don't really care) if that's standard SQL. If you need to
stick with it can we have an extension back to the old behaviour. PLEASE and
quickly? >>

I'm afraid not.  The right-trimming also caused issues in DBISAM that you
might not be aware of, such as fouling up locates on strings with padding
after the search string.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Just to remind you of an earlier post of yours

================================================================
Michael,

<< Is the VarChar on the above Screenshot means the "Real" VarChar ? =) >>

No, it's the same old VarChar as DBISAM with fixed space usage of the
declared size.

--
Tim Young
Elevate Software
www.elevatesoft.com
==================================================================


Which is right? This or the migration guide?

Roy Lambert

Tim


And the difference between me right trimming a field and the engine right trimming the same field is?

Roy Lambert

Roy,

<< Which is right? This or the migration guide? >>

Which part are you referring to ?  Are we still talking about
right-trimming, or how much physical space a VARCHAR uses up on disk ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< And the difference between me right trimming a field and the engine right
trimming the same field is? >>

One can be turned on and off as needed and the other can't.  True
SQL-standard VARCHARs include spaces if that is what the user/developer
entered into the field, even if they're trailing.

--
Tim Young
Elevate Software
www.elevatesoft.com