Database connect / PDO

[Jon Franz]

> Can you present a use case ? display_size is predefined statically in
> ODBC:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odappdpr_28.asp
>
> I can't think of any use case for internal size...

Variable length character (or binary) fields...
I've written many a piece of code over the years that has had to
create dynamic edit forms for a database. Variable length
character fields are common place, and I've always found that
enforcing the limit at edit time, rather than letting an error be
raised or data be silently truncated, is a good practice.

> Good catch :-) I'll fix that. It was true for mxODBC 1.x.

No worries.

> > If this is why the documentation says nearly, then your interpretation
> > of what 100% would mean is different from mine.  100% compliant
> > would, in my mind, be supporting all required interfaces.  I wouldn't
> > think optional interfaces are needed for compliance, and supporting
> > them, although good, wouldn't come into the percentage... unless you
> > wanted to say you were 105% compliant :)    .Just my two cents.
>
> Hmm, I am the editor of the DB API 2.0 spec...
>
> A database package can be 100% compliant without implementing
> all optional features. The DB API spec was designed to allow
> this since otherwise some modules would never be able to
> call themselves compatible.

That's exactly what I thought, and as my statement said, I was only trying
to figure out why 'nearly' was used, and then argue against the use if
all of the required features were already present.  A typo/slip-up makes
much more sense anyway. :)

cheers.

~Jon Franz
NeuroKode Labs, LLC