db-sig  

Messages by Thread

• • Re: [DB-SIG] Would like to challenge DBAPI on callproc's return value Milosz Kosmider
  • Re: [DB-SIG] Would like to challenge DBAPI on callproc's return value M.-A. Lemburg
  • Re: [DB-SIG] Would like to challenge DBAPI on callproc's return value Milosz Kosmider
• [DB-SIG] ANN: eGenix mxODBC Connect 2.1.5 - Remote Python Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC Connect 2.1.4 - Remote Python Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC 3.3.5 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC 3.3.4 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC 3.3.3 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC Connect 2.1.3 - Remote Python Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] SQLObject 3.0.0a1 Oleg Broytman
• [DB-SIG] SQLObject 2.1.2 and 1.7.5 Oleg Broytman
• [DB-SIG] ANN: eGenix mxODBC 3.3.2 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] SQLObject 2.1.1 and 1.7.4 Oleg Broytman
• [DB-SIG] "lists of tuples" vs. "tuples of tuples" Michael Bayer
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" M.-A. Lemburg
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" Michael Bayer
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" Vernon D. Cole
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" Michael Bayer
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" M.-A. Lemburg
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" Michael Bayer
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" Peter Eisentraut
  • Re: [DB-SIG] "lists of tuples" vs. "tuples of tuples" Michael Bayer
• [DB-SIG] SQLObject 2.1.0 Oleg Broytman
• [DB-SIG] Help with finding tutors for Python, Linux, R, Perl, Octave, MATLAB and/or Cytoscape for yeast microarray analysis, next generation sequencing and constructing gene interaction networks thomas hahn
• [DB-SIG] SQLObject 2.0 Oleg Broytman
• [DB-SIG] SQLObject 1.7.3 Oleg Broytman
• [DB-SIG] SQLObject 1.7.2 Oleg Broytman
• [DB-SIG] Improved support for prepared SQL statements SF Markus Elfring
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Daniele Varrazzo
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements SF Markus Elfring
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements SF Markus Elfring
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements SF Markus Elfring
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Tony Locke
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements SF Markus Elfring
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements INADA Naoki
  • Re: [DB-SIG] Improved support for prepared SQL statements INADA Naoki
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements Vernon D. Cole
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements INADA Naoki
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements INADA Naoki
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
  • Re: [DB-SIG] Improved support for prepared SQL statements Tony Locke
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements SF Markus Elfring
  • Re: [DB-SIG] Improved support for prepared SQL statements Michael Bayer
  • Re: [DB-SIG] Improved support for prepared SQL statements M.-A. Lemburg
• [DB-SIG] SQLObject 1.7.0 Oleg Broytman
• [DB-SIG] ANN: eGenix mxODBC Connect 2.1.2 - Python Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] Python: convert Hijri to Gregorian Date and vice versa Lucie Krennwallner
  • Re: [DB-SIG] Python: convert Hijri to Gregorian Date and vice versa M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC Connect 2.1.1 - Python Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] SQLObject 1.6.1 Oleg Broytman
• [DB-SIG] dsn syntax Wilson, Derek S
  • Re: [DB-SIG] dsn syntax Andy Todd
  • Re: [DB-SIG] dsn syntax M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC 3.3.1 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] how greedy should cursor.fetchmany be? Daniel Lenski
  • Re: [DB-SIG] how greedy should cursor.fetchmany be? M.-A. Lemburg
  • Re: [DB-SIG] how greedy should cursor.fetchmany be? Tony Locke
• [DB-SIG] ANN: eGenix mxODBC Connect 2.1.0 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] SQLObject 1.6.0 Oleg Broytman
• [DB-SIG] Announcing adodbapi version 2.6 Vernon D. Cole
• [DB-SIG] ANN: eGenix mxODBC Connect 2.0.5 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] stored procedure writing contest (not really, but please contribute) Vernon D. Cole
• [DB-SIG] SQLObject 1.5.2 Oleg Broytman
• [DB-SIG] ANN: eGenix mxODBC 3.3.0 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] Prepared statements in python drivers Daniele Varrazzo
  • Re: [DB-SIG] Prepared statements in python drivers M.-A. Lemburg
  • Re: [DB-SIG] Prepared statements in python drivers Tony Locke
  • Re: [DB-SIG] Prepared statements in python drivers M.-A. Lemburg
  • Re: [DB-SIG] Prepared statements in python drivers M.-A. Lemburg
  • Re: [DB-SIG] Prepared statements in python drivers Federico Di Gregorio
  • Re: [DB-SIG] Prepared statements in python drivers Peter Eisentraut
  • Re: [DB-SIG] Prepared statements in python drivers Vernon D. Cole
  • Re: [DB-SIG] Prepared statements in python drivers INADA Naoki
  • Re: [DB-SIG] Prepared statements in python drivers Federico Di Gregorio
  • Re: [DB-SIG] Prepared statements in python drivers INADA Naoki
• [DB-SIG] More tightly defining Cursor.callproc in PEP 249 Skip Montanaro
  • Re: [DB-SIG] More tightly defining Cursor.callproc in PEP 249 M.-A. Lemburg
  • Re: [DB-SIG] cursor.callfunc() (was: More tightly defining Cursor.callproc in PEP 249) M.-A. Lemburg
• [DB-SIG] ANN: eGenix mxODBC Connect 2.0.4 - Python ODBC Database Interface eGenix Team: M.-A. Lemburg
• [DB-SIG] SQLObject 1.5.1 Oleg Broytman
• [DB-SIG] Oracle+SQLA: Where are my tables? John W. Shipman
  • Re: [DB-SIG] Oracle+SQLA: Where are my tables? Michael Bayer
  • Re: [DB-SIG] Oracle+SQLA: Where are my tables? John W. Shipman
• [DB-SIG] asyncio support INADA Naoki
  • Re: [DB-SIG] asyncio support Tony Locke
  • Re: [DB-SIG] asyncio support INADA Naoki
  • Re: [DB-SIG] asyncio support M.-A. Lemburg
  • Re: [DB-SIG] asyncio support INADA Naoki
  • Re: [DB-SIG] asyncio support M.-A. Lemburg
  • Re: [DB-SIG] asyncio support Michael Bayer
• [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 Tony Locke
  • Re: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 Vernon D. Cole
  • Re: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 Daniele Varrazzo
  • Re: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 Tony Locke
• [DB-SIG] SQLObject 1.5.0 Oleg Broytman
• [DB-SIG] SQL Alchemy Database Architecture Question Weissberger, Daniel
• [DB-SIG] DBAPI 3.0: Unified parameter style Tony Locke
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style M.-A. Lemburg
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style Christoph Zwerschke
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style Vernon D. Cole
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style Vernon D. Cole
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style Tony Locke
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style Dieter Maurer
  • Re: [DB-SIG] DBAPI 3.0: Unified parameter style Vernon D. Cole
• [DB-SIG] mysql module embeds params in command string Carl Karsten
  • Re: [DB-SIG] mysql module embeds params in command string M.-A. Lemburg
  • Re: [DB-SIG] mysql module embeds params in command string Michael Bayer
  • Re: [DB-SIG] mysql module embeds params in command string Carl Karsten
  • Re: [DB-SIG] mysql module embeds params in command string Michael Bayer
  • Re: [DB-SIG] mysql module embeds params in command string Carl Karsten
  • Re: [DB-SIG] mysql module embeds params in command string Michael Bayer
• [DB-SIG] Fwd: Check out the Techblog about NuoDB's Python driver: Pynuodb! Lindsey Hoyem
• [DB-SIG] Notice: Restriction on adodbapi remote with Pyro4 v 2.20 Vernon D. Cole
• ACÍLIO JOÃO CARLOS MOREIRA DE CARVALHO ANDRADE Michael Klein
• [DB-SIG] adodbapi version 2.5.0 released Vernon D. Cole
• [DB-SIG] Make Python/SQL integration even smoother big stone
  • Re: [DB-SIG] Make Python/SQL integration even smoother Federico Di Gregorio
  • Re: [DB-SIG] Make Python/SQL integration even smoother M.-A. Lemburg
  • Re: [DB-SIG] Make Python/SQL integration even smoother M.-A. Lemburg
  • Re: [DB-SIG] Make Python/SQL integration even smoother Federico Di Gregorio
• [DB-SIG] SQLObject 1.3.3 and 1.4.1 Oleg Broytman
• [DB-SIG] Escaping parameter markers M.-A. Lemburg
  • Re: [DB-SIG] Escaping parameter markers Chris Clark
  • Re: [DB-SIG] Escaping parameter markers M.-A. Lemburg
• [DB-SIG] Two sample implementations of ['named', 'qmark'] auto switch (a report) Vernon D. Cole
  • Re: [DB-SIG] Two sample implementations of ['named', 'qmark'] auto switch (a report) Daniele Varrazzo
  • [DB-SIG] paramstyle specification (was: Two sample implementations of ['named', 'qmark'] auto switch (a report)) M.-A. Lemburg
  • Re: [DB-SIG] paramstyle specification (was: Two sample implementations of ['named', 'qmark'] auto switch (a report)) Michael Bayer
  • Re: [DB-SIG] paramstyle specification M.-A. Lemburg
  • Re: [DB-SIG] paramstyle specification Chris Clark
  • Re: [DB-SIG] paramstyle specification Carl Karsten
  • Re: [DB-SIG] paramstyle specification Vernon D. Cole
  • Re: [DB-SIG] paramstyle specification M.-A. Lemburg
  • Re: [DB-SIG] paramstyle specification Michael Bayer
  • Re: [DB-SIG] paramstyle specification M.-A. Lemburg
  • Re: [DB-SIG] paramstyle specification Michael Bayer
  • [DB-SIG] bind parameters Chris Clark
  • Re: [DB-SIG] bind parameters Chris Clark
  • Re: [DB-SIG] bind parameters and empty parameter lists M.-A. Lemburg
  • Re: [DB-SIG] bind parameters and empty parameter lists Chris Clark
  • Re: [DB-SIG] bind parameters and empty parameter lists Daniele Varrazzo
  • Re: [DB-SIG] bind parameters and empty parameter lists Chris Clark
  • Re: [DB-SIG] paramstyle specification (was: Two sample implementations of ['named', 'qmark'] auto switch (a report)) Daniele Varrazzo
  • Re: [DB-SIG] paramstyle specification (was: Two sample implementations of ['named', 'qmark'] auto switch (a report)) Vernon D. Cole
  • Re: [DB-SIG] paramstyle specification Niki Spahiev
• [DB-SIG] Test suite update for format conversion accuracy. Vernon D. Cole
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Daniele Varrazzo
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Carl Karsten
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Daniele Varrazzo
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Carl Karsten
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Michael Bayer
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Vernon D. Cole
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Daniele Varrazzo
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Vernon D. Cole
  • Re: [DB-SIG] Test suite update for format conversion accuracy. Carl Karsten
• [DB-SIG] SQLObject 1.4.0 Oleg Broytman
• [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Vernon D. Cole
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) M.-A. Lemburg
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Michael Bayer
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) M.-A. Lemburg
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Vernon D. Cole
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Christoph Zwerschke
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Michael Bayer
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Vernon D. Cole
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Daniele Varrazzo
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Christoph Zwerschke
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Daniele Varrazzo
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Christoph Zwerschke
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Michael Bayer
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Daniele Varrazzo
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Christoph Zwerschke
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) Dieter Maurer
  • Re: [DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable) M.-A. Lemburg

• Earlier messages
• Later messages