[dev] MSSQL portability options
Jan Schneider
jan at horde.org
Wed Jan 18 03:34:43 PST 2006
Zitat von Ben Chavet <ben at horde.org>:
> Ok, I think I've got the root of the mssql issues figured out. It
> seems that when mssql returns an "empty" string, it could really be an
> empty string, or it could be a string of one or more spaces, making
> empty-string comparisons fail. Yeah, it's dumb, I know. BUT, the
> pear DB package has a portability option to take care of that,
> DB_PORTABILITY_RTRIM, which just does an rtrim on all of the values
> returned.
>
> So, how much of a performance hit would it be to turn on that flag for
> other databases? It needs to be turned on for mssql, so do we turn it
> on by default with the other portability flags we use, or do we make
> mssql a special case, and make the code a bit uglier?
I would make it per db, like we already do it in Kronolith. BTW, that
reminds that we had the same problem with Oracle where we used CHAR
fields instead of VARCHAR. CHAR fields were always padded to the full
length. Do we leave Oracle alone because it can be fixed by using the
correct column types, or do we want to RTRIM them too, to be on the
safe side?
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
More information about the dev
mailing list