Tim

I don't know what other's views are but for me this one is a showstopper.

Unless there is a simple way to remove trailing spaces from some form of character field (I don't care if its VARCHAR or an ElevateDB enhancement TRIMEDCHAR) or an extra flag (eg VARCHAR(nn) TRIMMED) I won't be using ElevateDB.

By simple I mean something that can be set up preferably at the Engine level but certainly no lower than table to guarantee removal of trailing spaces without my having to type in every field name (so I can't miss one). I'm not prepared to do it at component level (been there done it, suffered).

My reason is simple, and illustrated in the attached image, it make validating data input difficult in a real life situation, can easily result in duplicates, and make finding the correct record difficult to say the least.

_ID is the primary key for the table. To the human eye I now have two records with the same id. ElevateDB knows they are different because one has trailing spaces. I entered it and I've forgotten how many. I doubt you can tell by looking at it or at a print out.

I hope you can suggest an acceptable solution for me. If not I suppose I have a year to persuade you to change your mind before DBISAM is terminated.

Roy Lambert

Roy,

<< By simple I mean something that can be set up preferably at the Engine
level but certainly no lower than table to guarantee removal of trailing
spaces without my having to type in every field name (so I can't miss one).
I'm not prepared to do it at component level (been there done it, suffered).
>>

I'll see what I can do, but it may or may not be possible.  The design of
EDB was done without this in mind.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Trying to find another old post I came across this.

><< By simple I mean something that can be set up preferably at the Engine
>level but certainly no lower than table to guarantee removal of trailing
>spaces without my having to type in every field name (so I can't miss one).
>I'm not prepared to do it at component level (been there done it, suffered).
> >>
>
>I'll see what I can do, but it may or may not be possible. The design of
>EDB was done without this in mind.

Any chance for V2?

Roy Lambert

Roy,

<< Any chance for V2? >>

Well, if not then, then pretty soon thereafter.  See my email to everyone
that we're sending out shortly.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Well, if not then, then pretty soon thereafter.

Brill

>See my email to everyone that we're sending out shortly.

Why are you sending people out, and how do I get hold of a copy of their email?

Roy Lambert

Roy,

<< Why are you sending people out, and how do I get hold of a copy of their
email? >>

I know, I know - I write very convoluted sentences sometimes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,
we are doing Production Data Aquisation or Time Management or "I don't know the english
word for it"
so we realy need and use TimeStamp extensively. All the SQLs in the Programm may be
fixable with
an FormatSQL Function so that "TIMESTAMP" is added to the Date and/or Time Value, ok.
We can change the Date Format to this UTC. But we have a view thousends of customers with
customized accounting macros, makros in reports and statistics.  
Is it possible to get rid of that TIMESTAMP Prefix ? May be per Module?
Is there a reason for this Prefix? From my point of view you get to know the type of the
expression by the fieldtype anyway.

Is it possible in some way to localize the date format?
If not is it possible to Trigger the field before the Datestring is parsed?

Please help.

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

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

<< we are doing Production Data Aquisation or Time Management or "I don't
know the english word for it"
so we realy need and use TimeStamp extensively. All the SQLs in the
Programm may be fixable with an FormatSQL Function so that "TIMESTAMP" is
added to the Date and/or Time Value, ok. We can change the Date Format to
this UTC. But we have a view thousends of customers with customized
accounting macros, makros in reports and statistics.  Is it possible to get
rid of that TIMESTAMP Prefix ? May be per Module? Is there a reason for this
Prefix? From my point of view you get to know the type of the expression by
the fieldtype anyway. >>

The prefixes are part of the SQL 2003 standard, so no, we cannot get rid of
them or change them.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
<<
The prefixes are part of the SQL 2003 standard, so no, we cannot get rid of
them or change them.
>>

Well, ok that is a good argument.
Sorry, but I was unaware that this is ANSI SQL 2003 standard,
because I never saw this kind of notation and I never read this very bulky SQL2003 standard.

<< Well, ok that is a good argument.
Sorry, but I was unaware that this is ANSI SQL 2003 standard,
because I never saw this kind of notation and I never read this very bulky
SQL2003 standard. >>

Well, I don't agree with everything in the standard, but I've tried to keep
things as close as possible to the SQL 2003 standard in terms of literal
values and other simple constructs.

--
Tim Young
Elevate Software
www.elevatesoft.com