[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