Date: 12/12/98
- Next message: nyenyon: "[PHP-DEV] CVS update: php3"
- Previous message: Andreas Karajannis: "Re: [PHP-DEV] My final say on Empress RBDMS and PHP"
- In reply to: Andreas Karajannis: "Re: [PHP-DEV] My final say on Empress RBDMS and PHP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andreas Karajannis wrote:
> Steve Williams wrote:
>
> > I THINK that the data should NEVER be displayed in a HTML table,
> > therefore the code should be:
> >
> > case SQL_LONGVARBINARY:
> > php3_printf("<td>Not printable</td>");
> > break;
> >
>
> You are right, but the whole binary handling has to take into account,
> that
> there are many users that use Access with uodbc. Unfortunately, the
> popular
> Access "Memo" fields are of type LONGVARBINARY - but mostly contain just
> text. In earlier versions of uodbc, binary columns never got displayed
> in tables and got passed through to the client by odbc_result(). To
> resolve this, odbc_binmode and odbc_longreadlen were introduced to allow
> Access users to display their data. This handling may be a little bit
> confusing, but allows for maximum flexibility.
>
> -Andreas
>
OK, that seems reasonable. But does this mean that an application writer
should set binmode before using the odbc_result_all function, or should I do
something specific for Empress (something I hope to avoid - the fewer #ifdef
VENDOR lines the better...).
I suppose the point is fairly unimportant because (I expect) most app
developers would not leave binary objects in their SELECT statements for HTML
pages :-?
Steve
-- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe <email protected> For help: php-dev-help <email protected>
- Next message: nyenyon: "[PHP-DEV] CVS update: php3"
- Previous message: Andreas Karajannis: "Re: [PHP-DEV] My final say on Empress RBDMS and PHP"
- In reply to: Andreas Karajannis: "Re: [PHP-DEV] My final say on Empress RBDMS and PHP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

