[DB-SIG] Announcement: adodbapi source code moved to pywin32/adodbapi

(adodbapi is a pure-Python PEP-249 compliant SQL interface for Windows using Microsoft ADO. It can access numerous database engines using ADO providers or ODBC drivers, and features such leading-edge enhancements as named-column data retrieval and user-selected query parameter styles.) For anyone

Re: [DB-SIG] Should Binary accept unicode string?

Mike: Thank you for your long explanation. I got lost somewhere in the middle there, though. If you are suggesting that better documentation be added to PEP-249, then perhaps you could include a suggestion as to a (brief) note which could be appended. If you are suggesting that the PEP be expa

Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples"

Recent versions of adodbapi do in fact return a result set ("Rows") object. Since ADO requires a separate operating system call to fetch each row, and since we can assume that the ADO result set is setting around in memory somewhere, I did not want the space overhead of making an additional copy of

Re: [DB-SIG] DBAPI 3.0: Unified parameter style

It happens that the statement "there is no reliable way to distinguish a mapping from a sequence" is not true. I submit the following example. Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] > on win > 32 > Type "help", "copyright", "credits" or "license" for more infor

Re: [DB-SIG] Improved support for prepared SQL statements

1) There is already an established usual practice (or quasi-standard) for prepared statements: >>> sql_stmt = "some sql string" >>> cursr.prepare(sql_stmt) >>> cursr.execute(sql_stmt, args) # note: the statement string must be >>> identical Any change in sql_stmt undoes the prepared status and th

[DB-SIG] Announcing adodbapi version 2.6

For more information, see http://adodbapi.sourceforge.net Tests were run against various combinations of: [Python2.5, Python2.7, Python3.3, Python3.4, IronPython2.7] [32-bit, 64-bit] [local, remote] [Access database, SQL Server, PostgreSQL, MySQL] This release adds prepared query support using t

[DB-SIG] stored procedure writing contest (not really, but please contribute)

Dear Sig-ites: I am in the process of expanding the test coverage for adodbapi. I have working tests for stored procedure operation for MS SQL Server, but my feeble efforts to write working "sproc"s for PostgreSQL and MySQL were dismal failures. So... I am soliciting code... I have put my unit

Re: [DB-SIG] Prepared statements in python drivers

Let me (as the maintainer of a competing product) be the one to say this: If prepared statements were to become standardized (either by an extension of PEP-249 or by a new Python3 compatible PEP) it should be simply a codification of the existing API used by mxodbc. (see mxODBC.pdf

Re: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3

I don't think that fetchmany() or its brothers will, or should, go away. I, for one, want api3 to be backwards compatible. I suspect, however that use of the iterator will become the prevalent pattern in the future. I am +1 on iterable cursors being required for API 3. I am starting a project j

Re: [DB-SIG] DBAPI 3.0: Unified parameter style

Tony: I should also mention that the reason that "qmark" ("?") delimiters were selected as the choice for specified-by-order parameter markers, rather than "numeric" (":n") in simply popularity. Postgres is pretty much alone in using numeric, where several other popular databases all use qmark.

Re: [DB-SIG] DBAPI 3.0: Unified parameter style

Tony: You are not the first one to notice that .paramstyle is rather an obtuse and ungainly creature. I also submitted a suggestion that introspection of the second argument to exectute() could potentially make it nearly obsolete (when there are only two alternative choices). As you have see

[DB-SIG] Notice: Restriction on adodbapi remote with Pyro4 v 2.20

Anyone trying the new ADO remote/proxy feature of adodbapi: Pyro 2.20 (just released) uses a new serializer which does not handle decimal or datetime data types. If you update your Pyro4, you need to switch back to the old pickle serializer by defining the environment variable PYRO_SERIALIZER=pic

[DB-SIG] adodbapi version 2.5.0 released

Because I need it for continued work on the django-mssql upgrade, I have released adobapi in its current state (including the optional feature of being able to auto-select between 'qmark' and 'named' paramstyles by requesting a paramstyle of 'auto'.) It continues to be fully dbapi 2.0 compliant.

Re: [DB-SIG] paramstyle specification (was: Two sample implementations of ['named', 'qmark'] auto switch (a report))

The major difference -- the change of paradigm (to put it in elegant terms) -- between api 2 and our proposed api 3, is our use of 'paramstyle'. In api 2, we attempted to use it to tell our client programmer how to talk to us. That did not work out too well. In api 3, we propose to offer the serv

Re: [DB-SIG] paramstyle specification

I think that we should be careful not to mandate any sophisticated grammar processing of the query string. The most notice we should take of comments would be to suggest that any reformatting operation might choose to stop at a double dash. /* C style */ comments and other non-ANSI-standard stand

[DB-SIG] Two sample implementations of ['named', 'qmark'] auto switch (a report)

There have been a few comments that automatically detecting SQL parameter style based on the container that parameters are passed in might not work. I have discovered that sometimes trying to put something in code sheds a lot of light on my understanding, so I decided to try it. Indeed, my last com

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

I just now realized that my quickly typed SUBJECT: line may have been the cause for misunderstanding here... It should have been "...limiting *mandatory* praramstyle to ['named','qmark']..." There has never been a suggestion that you cannot optionally support others .. just that you must support

Re: [DB-SIG] Test suite update for format conversion accuracy.

Daniele, Daniele, Daniele: Calm down. It's only a __TEST__. It doesn't restrict _anything_. If you look in qmarkpg/tests/dbapi20.py, you will see code for Python 3 support, some of which is actually forbidden by PEP 249 -- because Python 3 did not exist when the PEP was written. We (*) had t

Re: [DB-SIG] Test suite update for format conversion accuracy.

On Mon, May 20, 2013 at 8:12 AM, Daniele Varrazzo < daniele.varra...@gmail.com> wrote: > On Mon, May 20, 2013 at 12:51 PM, Vernon D. Cole > wrote: > > Stuart: > > > > I have just uploaded a branch for your consideration for > > https://code.launchpad.net/db

[DB-SIG] Test suite update for format conversion accuracy.

Stuart: I have just uploaded a branch for your consideration for https://code.launchpad.net/dbapi-compliance. This version adds a second field to the second test table (barflies) and loads that field with the literal 'thi%s :may cau%(e)s? troub:1e'. The value of this literal is a trap for unwary

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

<<\shirt>> Now, you have had a user request. Please don't just take your ball and go home. That will not stop the ball game, but it will rain on it. Work with us. -- Vernon Cole On Sat, May 18, 2013 at 8:22 PM, Daniele Varrazzo < daniele.varra...@gmail.com> wrote: > O

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

Dear Daniele: I spent some time this morning considering your long and well presented appeal. At my age, I have to walk, rather than run, for exercise, and it helps give me a lot of time to think. I have experience in a small, monolithic shop like the one you hypothesize in your example. I sa

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

I am worried about what the module-level attribute does to thread-safety. If this feature is kept, it should be a class attribute, not a module attribute. We should be doing connections using new style classes. conn = dbapi_module.Connection() conn.paramstyle = 'oddball' conn.connect(your, parame

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

On Fri, May 17, 2013 at 6:00 PM, M.-A. Lemburg wrote: > > IMHO it is explicit, whether you say: > > > > cursor.execute(stmt, { < dictionary>} ) > > > > vs. > > > > cursor.execute(stmt, [ ] ) > > > > the type of parameters passed indicates the style of params to search > for. It's explicit via t

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

deprecated or version specific) parameter styles. But I want that old behaviour to be optional. Think of a "from __past__ import paramstyle" feature. ;-) -- Vernon Cole On Fri, May 17, 2013 at 4:57 PM, M.-A. Lemburg wrote: > On 17.05.2013 17:44, Vernon D. Cole wrote: > > On F

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

On Fri, May 17, 2013 at 4:36 PM, M.-A. Lemburg wrote: > e.g. passing a > dictionary of parameters to a SQL command which uses a mix > of qmark and named style parameter markers. > That is a plain, simple syntax error, and will be reported as such by the SQL engine, along with a million other syn

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

termine the style by scanning the SQL is expensive and not a sure thing. On Fri, May 17, 2013 at 4:15 PM, Michael Bayer wrote: > > On May 17, 2013, at 11:10 AM, Christoph Zwerschke wrote: > > > Am 17.05.2013 17:01, schrieb Vernon D. Cole: > > > What other options should

Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

more I think about it, the more it seems unnecessary. What other options should be considered? -- Vernon On Fri, May 17, 2013 at 2:59 PM, Michael Bayer wrote: > > On May 17, 2013, at 6:42 AM, M.-A. Lemburg wrote: > > > On 17.05.2013 12:09, Vernon D. Cole wrote: > &g

[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

I short time ago I commented to this forum that the 'format' paramstyle was important to keep, because of widespread use, citing django as an example. I have taken the question to the django developers group and received a response that they don't really like the 'format' paramstyle and would be h

[DB-SIG] should precision and sign of decimal(0) be significant?

I am working on code (django-mssql) where I found the following test: ##expected = ( ##Decimal('0.00'), ##Decimal('0.0'), ##Decimal('-0.00')) ## ##cur = con.cursor() ##cur.paramstyle = 'format' # a nonstandard ex

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

I forgot: pywin32 just dropped support for Python 2.3 so I can use decorators now. Michael, you have just contributed four lines of code to the next version of adodbapi. -- Vernon On Thu, May 2, 2013 at 11:30 AM, Michael Bayer wrote: > > On May 2, 2013, at 1:12 PM, Vernon D. Cole

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

So -- here is a prototype... > >>> import adodbapi > > >>> c = adodbapi.connect("provider=Microsoft.ACE.OLEDB.12.0;data >> source=../examples/test.mdb") > > >>> c > > > > >>> c.dbapi > > > 'C:\Python27\lib\site-packages\adodbapi\apibase. > > pyc'> > > >>> c.dbapi.NUMBER > > > > My implementatio

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

I think that "database" as the property identifier carries too much baggage -- there are too many meanings of, and too much use of the term, therefore it is not immediately obvious what the property might be used for. It reads well, but does not have an "ahha!" factor. connection.dbapi does. I t

[DB-SIG] Announcing Beta test of adodbapi v2.5 with Linux remote module

Beta test is now available for adodbapi version 2.5 -- !!! NOW WORKS FROM LINUX !!! (as a remote client) -- ADO is Microsoft's update for ODBC, and can be used to open almost any tabular data source in existance. I have personally used adodbapi to read tables from: SQL Server, PostgreSQL, MySQL, J

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

Yes, I _like_ that idea. I'm not so sure about "database" being the correct name for the attribute, but the idea itself is the correct "obvious way to do it", I think. I have just finished tearing all of the cruft stuff (exceptions, translations, etc) out of adodbapi into a separate module so th

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

One of those attributes needs to move anyway. In order to make the paramstyle switchable, it needs to be an attribute of the connection, so that a client who is supporting multiple connections to multiple engines (like, for example the database connection server I am writing right now) does not ha

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

Dan: You have a very good point. Perhaps we should put that on the wish list for API version 3. The .connection attribute of the cursor is optional. IMHO it should be required.. I think most existing api packages implement it. The it is suggested, but not required by the PEP, that the excepti

Re: [DB-SIG] checking column types from cursor object in a database-independent way?

Give the restriction you mention (that you have only the cursor object) the solution you propose looks pretty good. The cursor.connection attribute is an extension, but I think most api modules provide it. On Fri, Apr 19, 2013 at 11:56 AM, Dan Lenski wrote: > Hi, > I have to dump some data fr

[DB-SIG] remote Windows database access tool building

Dear group: I am seeking your wisdom and advice. Here is my situation: I am working for a small company (eHealthAfrica.org) who has taken a contract to build a software system to be used in collecting and analyzing data relating to polio vaccination efforts in northern Nigeria. (This area conta