Hi Peter,
On 29.03.2021 13:48, Peter Norman wrote:
> Hi Python DB Folks.
>
> Is PEP 249 at https://www.python.org/dev/peps/pep-0249/ the correct / latest
> one?
>
> While I am new to python, this seems to be written for python 2.* and not
> python
> 3.*, or have I missed something?
It was wri
On 20.10.2018 19:13, Mike Bayer wrote:
>
>
> On Sat, Oct 20, 2018, 5:02 AM M.-A. Lemburg <mailto:m...@egenix.com>> wrote:
>
> On 18.10.2018 16:07, Mike Bayer wrote:
> > On Thu, Oct 18, 2018 at 5:46 AM M.-A. Lemburg <mailto:m...@egenix.com>>
On 18.10.2018 16:07, Mike Bayer wrote:
> On Thu, Oct 18, 2018 at 5:46 AM M.-A. Lemburg wrote:
>>
>> On 16.10.2018 16:37, Mike Bayer wrote:
>>> AFAIK , Postgresql is the only major relational database that has an
>>> actual non-blocking protocol.The other data
es
its own wire protocol) via gevent a long time ago and it works
well in that context. We did not introduce any API changes
for this, only a config option to enable support:
https://www.egenix.com/products/python/mxODBCConnect/doc/#_Toc433125695
> On Tue, Oct 16, 2018 at 6:02 AM M.-A. Lem
On 16.10.2018 13:00, M.-A. Lemburg wrote:
> Hi Nadar,
>
> we do have a set of things scheduled for a version 3.0 of
> the DB API (see the python.org wiki), but nothing related to
> async I/O yet.
https://wiki.python.org/moin/DbApi3
> FWIW: I think the existing APIs can be use
Hi Tom,
there are already a number of standard DB-API compatible modules
for Sybase, DB2 and PostgreSQL which you can readily use.
Please check the python.org wiki for links:
https://wiki.python.org/moin/DatabaseInterfaces
Regarding donations to the PSF, please contact p...@python.org for
detai
Hi Nadar,
we do have a set of things scheduled for a version 3.0 of
the DB API (see the python.org wiki), but nothing related to
async I/O yet.
FWIW: I think the existing APIs can be used in an async form
as well, without having to specify new ones, by simply
providing an async entry point at the
Hi Birgit,
if you are using zxJDBC on Jython to connect to the database,
you should be able to use the same (or a similar) connection
string.
On CPython, you will either have to use a custom DB API compatible
interface module for Hive2 or go with an ODBC module and
access Hive2 using an ODBC driv
The DB-API 2.0 was released on 1999-04-12. However, the
creation process took a few weeks and the much of the
DB-API 2.0 is based on the DB-API 1.0 (PEP 248, which was
developed in 1996):
https://mail.python.org/pipermail/db-sig/1999-March/000762.html
On 20.08.2017 22:16, Nathan Guerin wrote:
>
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.6
mxODBC is our commercially supported Python extension providing
On 24.06.2016 16:31, Sigurd Jervelund Hansen wrote:
> Hi
>
> I'm using the PEP249 as a reference, and I've stumbled upon some
> contradicting documentation in footnote 1.
>
> If I attempt to connect to a database using the example I get the following
> error:
>
connect(host=dbHost,user=dbUs
On 27.04.2016 15:14, Edilson Santos wrote:
> Hi,
> I'm using a Michael Halls-Moore's source code, posted on
> https://www.quantstart.com/articles/Forecasting-Financial-Time-Series-Part-1
> The original code import the Yahoo's data, using a user-defined function.
> This function imports the data set
Hello Madhu,
I am not sure how your posting is relevant to this mailing
list. Most of your questions seem to have to do with OS
permissions and storing/restoring files.
You can store the necessary details in a database, but the
actual logic for managing the files themselves will have
to be done u
On 16.01.2016 16:27, Mike Bayer wrote:
>
>
> On 01/15/2016 05:14 PM, Vernon D. Cole wrote:
>> 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 coul
On 15.01.2016 16:52, Mike Bayer wrote:
>
>
> On 01/15/2016 09:47 AM, M.-A. Lemburg wrote:
>> On 12.01.2016 13:59, INADA Naoki wrote:
>>> Hi, all.
>>>
>>> I found DB-API 2.0 defines Binary() as Binary(string).
>>> https://www.python.org/dev/
On 12.01.2016 13:59, INADA Naoki wrote:
> Hi, all.
>
> I found DB-API 2.0 defines Binary() as Binary(string).
> https://www.python.org/dev/peps/pep-0249/#binary
>
> What the string means?
> On Python 2, should Binary accept unicode?
> On Python 3, should Binary accept str?
The Binary() wrapper i
On 06.12.2015 20:10, Milosz Kosmider wrote:
> Hi Marc-Andre, Mike,
>
> Thanks for responding and setting me straight on the spec! Being that
> PostgreSQL is a little bit unique in that it always returns its INOUT/OUT
> parameters in the result set and provides no other way to access their
> values
Hi Milosz,
On 01.12.2015 06:40, Milosz Kosmider wrote:
> Hi folks,
>
> As PostgreSQL has had named parameters in stored procedures since version
> 9.0, I
> have taken to adding support for the feature in the DBAPI-complicant Python
> wrapper, psycopg2: https://github.com/psycopg/psycopg2/pull/16/
ANNOUNCING
eGenix.com mxODBC Connect
Remote Python Database Interface
Version 2.1.5
mxODBC Connect is our commercially supported client-server product
ANNOUNCING
eGenix.com mxODBC Connect
Remote Python Database Interface
Version 2.1.4
mxODBC Connect is our commercially supported client-server product
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.5
mxODBC is our commercially supported Python extension providing
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.4
mxODBC is our commercially supported Python extension providing
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.3
mxODBC is our commercially supported Python extension providing
ANNOUNCING
eGenix.com mxODBC Connect
Remote Python Database Interface
Version 2.1.3
mxODBC Connect is our commercially supported client-server product f
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.2
mxODBC is our commercially supported Python extension providing
On 03.02.2015 21:30, Michael Bayer wrote:
>> [By the way, both Rows and Row objects are made immutable, so that an unwary
>> programmer does not receive an unwelcome surprise by attempting to alter
>> data without using an SQL statement.]
>
> I would actually favor the result list to be an immut
On 01.02.2015 22:47, Michael Bayer wrote:
> Hi -
>
> May I get clarification from pep-249 regarding the contract for fetchall()
> and fetchmany(), as to if it is acceptable and/or recommended that these
> methods return tuples of tuples, as opposed to lists of tuples?
>
> In my experience, whil
On 21.12.2014 20:56, Michael Bayer wrote:
>
>
> M.-A. Lemburg wrote:
>
>>
>> Whether or not a cursor is client or server side depends on many
>> things and is generally database backend specific. MS SQL Server
>> for example will default to server side curs
On 21.12.2014 20:46, Michael Bayer wrote:
> M.-A. Lemburg wrote:
>>> However, getting back to the issue of prepared statements, I will note that
>>> specific to MySQL, MySQL’s own DBAPI driver, MySQL-connector-Python, does in
>>> fact tie the prepared sta
On 19.12.2014 00:12, Michael Bayer wrote:
> M.-A. Lemburg wrote:
>> I think there's a misunderstanding here. A named cursor refers to
>> a database cursor pointing into a result set. Once that result
>> set has been created and the cursor points to it, you cannot
>>
On 21.12.2014 19:40, Michael Bayer wrote:
>
>
> M.-A. Lemburg wrote:
>
>>
>> My experience is from working with ODBC and ODBC drivers.
>> IBM DB2 and MS SQL Server use ODBC as their native database
>> interface API. In ODBC, cursors are called "
On 18.12.2014 23:19, Michael Bayer wrote:
>
>> On Dec 18, 2014, at 3:57 PM, Michael Bayer wrote:
>>
>>>
>>> On Dec 18, 2014, at 3:39 PM, M.-A. Lemburg wrote:
>>>
>>>
>>>> That would make the entire feature a non-starter for me
On 18.12.2014 21:57, Michael Bayer wrote:
>
>> On Dec 18, 2014, at 3:39 PM, M.-A. Lemburg wrote:
>>
>>
>>> That would make the entire feature a non-starter for me.SQLAlchemy
>>> doesn’t hold cursors open beyond a single statement.My users would v
On 18.12.2014 21:23, Michael Bayer wrote:
> Basically I want there to be very good reason for this feature to be an
> explicit part of the DBAPI because it is going to give me personally a lot of
> extra headaches when people start asking for it in the name of “performance”,
> especially since t
On 18.12.2014 16:59, Michael Bayer wrote:
>
>> On Dec 18, 2014, at 5:39 AM, M.-A. Lemburg wrote:
>>
>> On 17.12.2014 19:13, INADA Naoki wrote:
>>> As I said before, prepared statement is normally bound to connection.
>>> So `.prepare()` method shou
On 18.12.2014 12:27, INADA Naoki wrote:
> On Thu, Dec 18, 2014 at 7:39 PM, M.-A. Lemburg wrote:
>> On 17.12.2014 19:13, INADA Naoki wrote:
>>> As I said before, prepared statement is normally bound to connection.
>>> So `.prepare()` method should be connec
On 17.12.2014 19:13, INADA Naoki wrote:
> As I said before, prepared statement is normally bound to connection.
> So `.prepare()` method should be connection's method, not cursor's.
>
> prepared = conn.prepare("SELECT ?+?")
> ...
> cur = conn.cursor()
> cur.execute(prepared, (1, 2))
> cur.fetchone
sn't provide a way to say
"prepare this SQL for execution, but don't execute it
just yet".
> Regards,
>
> Tony.
>
> On 17 December 2014 at 17:54, Michael Bayer wrote:
>>
>>> On Dec 17, 2014, at 10:41 AM, M.-A. Lemburg wrote:
>>>
>>>
On 17.12.2014 18:54, Michael Bayer wrote:
>
>> On Dec 17, 2014, at 10:41 AM, M.-A. Lemburg wrote:
>>
>>
>> Another possibility is to write a layer on top of the DB-API
>> to abstract the underlying queries away from the application
>> and only have the
On 17.12.2014 16:18, SF Markus Elfring wrote:
>> Please explain what you want in more detail, so we can check
>> whether there's room for improvement :-)
>
> Can the SQL update statement be encapsulated by a dedicated Python
> class for example?
Sure. You could write a class that only supports up
On 17.12.2014 15:38, SF Markus Elfring wrote:
>>> Can the prepare() method return a handle for a SQL statement?
>>
>> The proposal says:
>>
>> """
>> Return values are not defined.
>> """
>
> How do you think about to change the application programming
> interface here?
>
> Would a class like "pr
On 17.12.2014 14:50, SF Markus Elfring wrote:
>> How about:
>>
>> """
>> The prepared operation is only available until the next call to
>> one of the .execute*() methods or another call to the .prepare()
>> method using a different command string than the one used for
>> preparing the previous ope
On 09.12.2014 13:24, Daniele Varrazzo wrote:
> On Tue, Dec 9, 2014 at 9:40 AM, M.-A. Lemburg wrote:
>> On 07.12.2014 22:06, SF Markus Elfring wrote:
>>> Hello,
>>>
>>> An interface for parameterised SQL statements (working with
>>> placeholders) is pro
On 07.12.2014 22:06, SF Markus Elfring wrote:
> Hello,
>
> An interface for parameterised SQL statements (working with
> placeholders) is provided by the execute() method from the Cursor class
> at the moment.
> https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor.execute
>
> I assume th
ANNOUNCING
eGenix.com mxODBC Connect
Python Database Interface
Version 2.1.2
mxODBC Connect is our commercially supported client-server product for
Hello Lucie,
this list is about relational databases, not date/time questions.
You may get help on comp.lang.python or the Python tutor list:
https://mail.python.org/mailman/listinfo/tutor
BTW: The Hirji calendar is somewhat difficult to map to an algorithm,
due to its reliance on (official) si
ANNOUNCING
eGenix.com mxODBC Connect
Python Database Interface
Version 2.1.1
mxODBC Connect is our commercially supported client-server product for
On 20.08.2014 18:58, Wilson, Derek S wrote:
> What is the proper syntax for DSN? Is it only host:database or is there some
> other way to specify a DSN?
As others have noted, this is database module dependent.
The Python DB-API does not mandate a particular syntax for the
DSN field, since databa
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.1
mxODBC is our commercially supported Python extension providing
On 11.06.2014 03:06, Daniel Lenski wrote:
> I'm writing a DBAPI module for a custom database wrapper. The way I get
> data from a query is to ask the underlying database it for a chunk of rows,
> at which point it spits out an unpredictable number (it's a black box to
> me).
>
> I'm trying to figu
ANNOUNCING
eGenix.com mxODBC Connect
Python ODBC Database Interface
Version 2.1.0
mxODBC Connect is our commercially supported client-server product fo
ANNOUNCING
eGenix.com mxODBC Connect
Python ODBC Database Interface
Version 2.0.5
mxODBC Connect is our commercially supported client-server product fo
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.3.0
mxODBC is our commercially supported Python extension providing
On 27.03.2014 11:28, M.-A. Lemburg wrote:
> I don't think the use case is important enough to make .prepare()
> a requirement in the DB-API, but it would be great if we could
> come up with a standard extension definition.
Here's a start:
"""
.prepare(operat
On 26.03.2014 20:38, Tony Locke wrote:
> Hi Daniele, the latest release of pg8000 (1.9.7) has (experimental)
> support for prepared statements, but takes an implicit approach rather
> than an explicit one. In the connect() function there's a boolean
> use_cache parameter which tells pg8000 to cache
On 25.03.2014 00:06, M.-A. Lemburg wrote:
>> [Skip]
>> So, to draw this exceedingly long mail to a close, I propose:
>>
>> 1. PEP 249 should document how stored procedure return values are made
>>available to the caller of Cursor.callproc.
>
> Agreed,
Hi Skip,
sorry for the late reply. For some reason I did not see your
email to the list in my inbox.
On 13.03.2014 21:50, Skip Montanaro wrote:
> [...]
>
> After this episode, I was motivated to revisit PEP 249's discussion of
> stored procedures. I barely use SQL in my own work, relying heavil
Hi Daniele,
On 24.03.2014 17:53, Daniele Varrazzo wrote:
> Hello,
>
> lately there has been some interest in adding prepared statements
> support in Psycopg. It's a feature of which I see the usefulness but
> which I haven't used extensively enough to make my mind about be the
> best interface to
ANNOUNCING
eGenix.com mxODBC Connect
Python ODBC Database Interface
Version 2.0.4
mxODBC Connect is our commercially supported client-server product f
On 11.11.2013 10:43, INADA Naoki wrote:
> I think having definition about what method returns Future is good.
>
> For example:
>
> con = yield from pymysql.connect_async(...) # connection may cause
> cur = con.cursor() # cursor creation should done without asyncio
> yield from cur.execute("..."
On 12.11.2013 12:03, INADA Naoki wrote:
> On Tue, Nov 12, 2013 at 7:41 PM, M.-A. Lemburg wrote:
>
>> On 11.11.2013 10:43, INADA Naoki wrote:
>>> I think having definition about what method returns Future is good.
>>>
>>> For example:
>>
The wiki page is somewhat out of date and doesn't really reflect
what we've been discussing here on the list recently.
We're currently aiming for making the .paramstyle a user adjustable
setting and requiring support for two paramstyles 'qmark' and 'named',
while keeping the other paramstyles arou
Carl Karsten wrote:
> I feel I need to post this now and then in hopes I find someone who
> can do something about it. This might even be worth some PSF funding?
>
> I am not a security expert, I am not qualified to asses the risk, it
> doesn't matter if I consider this a vulnerability. That sai
On 18.07.2013 06:56, ISRAEL DA-COSTA-HOMEM wrote:
> Good night,
>
> I installed 2.0 pymssql this link http://www.lfd.uci.edu/ ~ Gohlke /
> pythonlibs / # pymssql, but the following error occurred below. I
> uninstalled and installed version pymssql 1.0.2 which worked perfectly.
> What might have g
ave to what you're suggesting is
pandas, which sort of provides ORM style SQL operations
on tables:
http://pandas.pydata.org/
I guess you could also write a SQL parser which transforms
the SQL or some Linq like dialect for Python into the method
calls for pandas.
> Regards,
>
>
> 2013
I think you are suggesting a new Python DB-API module for
accessing and querying Python namespaces.
This could probably be done by leveraging techniques from
Gadfly: http://gadfly.sourceforge.net/
Alternatively, you could mirror the namespaces into sqlite and
then use SQLite's SQL engine for the
On 23.05.2013 23:37, Chris Clark wrote:
> On Thu, 23 May 2013 13:33:20 -0700, Chris Clark
> wrote:
>> On Thu, 23 May 2013 16:59:27 +0200, M.-A. Lemburg wrote:
>>> On 22.05.2013 00:52, Michael Bayer wrote:
>>>> As a total aside, I also have issues with some DBAPI
On 23.05.2013 22:27, Chris Clark wrote:
> On Thu, 23 May 2013 17:44:35 +0200, M.-A. Lemburg wrote:
>> I've done some research on escaping parameter markers. Here's what
>> I came up with:
>>
>> ODBC: Supports only qmark ('?'). The standard doesn'
On 22.05.2013 00:07, Vernon D. Cole wrote:
> 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.
> /*
I've done some research on escaping parameter markers. Here's what
I came up with:
ODBC: Supports only qmark ('?'). The standard doesn't specify an
escape sequence for ? in SQL statements.
JDBC: Supports qmark ('?') and named (':param'). The standard
doesn't specify an escape sequence
On 22.05.2013 00:52, Michael Bayer wrote:
>
> On May 21, 2013, at 3:24 PM, M.-A. Lemburg wrote:
>
>> On 21.05.2013 20:55, Michael Bayer wrote:
>>>
>>> On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
>>>
>>>>
>>>> Something w
On 21.05.2013 20:55, Michael Bayer wrote:
>
> On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
>
>>
>> Something we do need to address in a paramstyle spec for
>> qmark and named is SQL comments. Perhaps easiest would be
>> to disallow them in SQL statemen
On 18.05.2013 03:29, Daniele Varrazzo wrote:
> On Fri, May 17, 2013 at 5:57 PM, M.-A. Lemburg wrote:
>>
>>> Reading back the upstream thread I also see proposal to leave support
>>> for all the current placeholders but mandate drivers to implement
>>> qmark
Wow, a lot of discussion to read :-)
I'll start with some comments on the more important things.
On 21.05.2013 19:24, Daniele Varrazzo wrote:
> On Tue, 2013-05-21 at 17:32 +0100, Vernon D. Cole wrote:
>> My conclusion: Auto switching is easy, practical, and has years of
>> precedent history. DB-
On 17.05.2013 19:52, Vernon D. Cole wrote:
> I am worried about what the module-level attribute does to thread-safety.
We should clearly document the fact that the module level
attribute serves as default value for new connections - it
should really only be set right after importing the module
or
On 17.05.2013 19:44, Michael Bayer wrote:
>
> On May 17, 2013, at 1:30 PM, M.-A. Lemburg wrote:
>
>> As for how to adjust the paramstyle, I think Vernon's summary
>> is a good one. SQLAlchemy and other applications could then
>> do (*):
>>
>> import d
Ok, I think we've heard all sides.
We have two extreme positions:
1. only allow qmark and named, let the driver figure out which one
is used
2. only allow format/pyformat
and the original idea of having an adjustable paramstyle,
with the only requirement that modules must provide the
two agr
On 17.05.2013 18:07, Michael Bayer wrote:
>
> On May 17, 2013, at 11:36 AM, M.-A. Lemburg wrote:
>
>> On 17.05.2013 17:10, Christoph Zwerschke wrote:
>>> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
>>>> What other options should be considered?
>>>
On 17.05.2013 17:50, Daniele Varrazzo wrote:
> Sorry, originally sent this message only to M.-A.L.
>
> On Fri, May 17, 2013 at 11:42 AM, M.-A. Lemburg wrote:
>> psychopg2 uses the 'format' paramstyle and while I agree that
>> it has issues, I think the existing
On 17.05.2013 17:44, Vernon D. Cole wrote:
> 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, simpl
On 17.05.2013 17:01, Vernon D. Cole wrote:
> Good point, the others would be optional.
>
> How should the switching be done? My present development head has four
> methods:
>
> 1) adodbapi.apibase.paramstyle = 'named'
> I think this one should be deprecated. Stepping on a module quasi-constant
On 17.05.2013 17:10, Christoph Zwerschke wrote:
> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
>> What other options should be considered?
>
> Another option would be to get rid of the parameter completely, and silently
> accept both styles,
> whatever is used in the sql command passed to the exe
On 17.05.2013 15:59, 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:
>>> I short time ago I commented to this forum that the 'format' paramstyle was
>>> important to keep, bec
On 17.05.2013 12:09, Vernon D. Cole wrote:
> 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
On 08.05.2013 11:48, Vernon D. Cole wrote:
> 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()
>
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.2.3
mxODBC is our commercially supported Python extension providing
;
>> # include connection attributes as class attributes required by api
>>> definition.
>>
>> dbapi = property(lambda cls: api)
>>
>> Warning = api.Warning
>>
>> ... (etc.)
>>>
>>
>> Is that what we want to
On 02.05.2013 15:53, Michael Bayer wrote:
>> Another readable candidate would be "connection.dbapi".
>
> +1 for connection.dbapi
Sounds like we're reaching consensus :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 02 2013)
>>> Python Project
On 23.04.2013 17:00, Daniel Lenski wrote:
> On Tue, Apr 23, 2013 at 12:29 AM, M.-A. Lemburg wrote:
>>
>> I don't think we should clutter up the connection objects with
>> module scope attributes that hardly ever get used.
>>
>> The exceptions are used
On 23.04.2013 16:41, Michael Bayer wrote:
>
> On Apr 23, 2013, at 3:29 AM, M.-A. Lemburg wrote:
>
>>
>>
>> A method doing the lookup via the sys.modules dictionary
>> could resolve those issues:
>>
>> database = connection.databa
On 22.04.2013 18:59, Michael Bayer wrote:
>
> On Apr 22, 2013, at 12:44 PM, Dan Lenski wrote:
>
>> Michael Bayer zzzcomputing.com> writes:
>>
>>> On Apr 21, 2013, at 9:39 PM, Daniel Lenski gmail.com> wrote:
>>>
I *could* pass around a handle to the DB module along with the cursor
>>>
On 19.04.2013 20:46, Michael Bayer wrote:
>
> On Apr 19, 2013, at 1:56 PM, Dan Lenski wrote:
>
>> Hi,
>> I have to dump some data from various databases (Oracle and Postgre, at the
>> moment) into CSV files, while preserving the column type information so the
>> data can be correctly loaded in
ANNOUNCING
eGenix.com mxODBC Connect
Python ODBC Database Interface
Version 2.0.3
mxODBC Connect is our commercially supported client-server product f
On 26.03.2013 12:15, Vernon D. Cole wrote:
> 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 v
ANNOUNCING
eGenix.com mxODBC
Python ODBC Database Interface
Version 3.2.2
mxODBC is our commercially supported Python extension providing
ANNOUNCING
eGenix.com mxODBC Connect
Python Database Interface
Version 2.0.2
mxODBC Connect is our commercially supported client-server product for
On 04.12.2012 15:55, wilk wrote:
> On 03-12-2012, M.-A. Lemburg wrote:
>> On 03.12.2012 09:31, wilk wrote:
>>> Hi,
>>>
>>> I did a litle function to use the same paramstyle regardless of the
>>> paramstyle of the database. I transform one paramstyl
On 03.12.2012 11:29, Daniele Varrazzo wrote:
> On Mon, Dec 3, 2012 at 9:01 AM, M.-A. Lemburg wrote:
>> On 03.12.2012 02:42, Daniele Varrazzo wrote:
>>> On Mon, Nov 5, 2012 at 9:28 AM, M.-A. Lemburg wrote:
>>>> On 04.11.2012 23:24, Christoph Zwerschke wrote:
>
On 03.12.2012 02:42, Daniele Varrazzo wrote:
> On Mon, Nov 5, 2012 at 9:28 AM, M.-A. Lemburg wrote:
>> On 04.11.2012 23:24, Christoph Zwerschke wrote:
>>> To wrap everything up, as a result of our discussion, I will do the
>>> following in the next version of
&
On 03.12.2012 09:31, wilk wrote:
> Hi,
>
> I did a litle function to use the same paramstyle regardless of the
> paramstyle of the database. I transform one paramstyle to an other (a
> code missing in the lib standard isn't it ?)
There are a few such libraries out there which take care of
such
1 - 100 of 334 matches
Mail list logo
