On May 14, 2012, at 10:33 AM, Edward Welbourne wrote:
>
> Most of SQL is sufficiently standardised to permit writing portable code
> to explore a database - provided access compatible with PEP 249 is
> available - without need to know details of the SQL implementation; so
> it would be nice if s
Vernon Cole:
> The problem with attempting to make a uniform tool for doing that at
> the PEP 249 level, is that some api packages (such as the one I
> maintain for Microsoft ADO, and anything that does ODBC) may attach to
> dozens of different engines.
Sounds painful. I'm not a database ex
On Tuesday 2012-05-15 10:16 (-0700), M.-A. Lemburg wrote:
What you're describing sounds a lot like the catalog methods in
the ODBC standard.
Those are typically implemented by either
having the ODBC drivers implement a set of queries that generate
result sets in a predefined format, or by addin
Edward Welbourne wrote:
> Hi DB-sig,
>
> I'm digging data out of my mobile 'phone so that I don't lose it during
> an upgrade. It turns out to hold my address-book in a sqlite database,
> so I duly connected to that using the pysqlite2 package; which
> implements PEP 249 (DB API 2.0) - indeed, th
On 15/05/12 12:06 PM, Vernon Cole wrote:
Eddy:
As you discovered, every different database system has a unique way
of getting a table listing. The problem with attempting to make a
uniform tool for doing that at the PEP 249 level, is that some api
packages (such as the one I maintain for Micr
Eddy:
As you discovered, every different database system has a unique way of
getting a table listing. The problem with attempting to make a uniform
tool for doing that at the PEP 249 level, is that some api packages (such
as the one I maintain for Microsoft ADO, and anything that does ODBC) may
