> Out of interest. Do YOU want trailing spaces? If so why?
>
> Roy Lambert

I do not want trailing spaces in  my applications so I alwasy trim
before posting, in case a end-user has added spaces by mistake, but I
have seen some apps that pad trailing spaces for display purposes.  I
do think that it should be the realm of the develper to either handle
this in their app or at least to have a switch in the dastabase engine
to turn this on or off.

--
David Farrell-Garcia
Whidbey Island Software, LLC

David


Brill. So where and how do you trim them?

Roy Lambert

Roy Lambert wrote:

> Brill. So where and how do you trim them?


I ususally do it in the  table.BeforePost event.

--
David Farrell-Garcia
Whidbey Island Software, LLC

Roy

Do you mean canned results using TRoyQuery ?
If so, you can override Post method from TRoyQuery to do so, check the
Origin table (remember SQL always have a driver table) and post the results
(canned) back to the original table (in the database).

Eduardo

Jose


Nope, I want to hit every insert or post to the underlying database pretty much as DBISAM does now.

Roy Lambert

Roy

Could you explain better what you mean ?

If you run a SQL statement INSERT INTO then DBISAM does not hit every insert
(exposed events), what you want is a source code of DBISAM and change this
behaviour.

Eduardo

Jose


The VARCHAR behaviour has changed between DBISAM and ElevateDB. With DBISAM VARCHAR fields are RTRIM()'d by the engine before being stored in the database. With ElevateDB trailing spaces will be left alone.

So enter "Smith    " in a field or via sql (the "s are simply so you know where the spaces are)

in DBISAM "Smith" will be stored in the database no matter what route it took to get there

in ElevateDB "Smith    " will be stored

In my view (and note it is only my view) only a mental defective would want the latter (and yes I know the standard says it should be allowed so  guess my view of the standard setters) with its potential for chaos and confusion. BTW I'm open to being convinced there is a good reason for keeping trailing blanks in VARCHARs, but bearing in mind some of the tortuous reasons put forward for null does not equal empty string (lots of hypothetical ones and one real one) I'm doubtful I shall be.

I can see some point in it if a single space has been entered to indicate "I didn't have anything to put into here but I didn't want to leave it empty" which is what I mean by tortuous reason.

What I want is to remove all the trailing spaces from VARCHARs prior to them hitting the database.

Eryk suggested modifying the beforepost event (at least I think that's the one he meant) to create my own components. That would work for tables, but I can't see it working for queries like "UPDATE Contacts SET _Forename = ' + Edit1.Text

What I don't want to have to do is have lots of code enforcing this behaviour all over the place with the concomitant maintenance problems. Been there, done it, hated it.

Hope that explains it enough.

Roy Lambert