informixdb-cvs Mailing List for InformixDB (Page 7)

Brought to you by: chaese, f-apolloner

informixdb-cvs — CVS commit notification mailing list

You can subscribe to this list here.

2005	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct (36)	_Nov (40)	_Dec (6)
2006	_Jan (1)	_Feb	_Mar (6)	_Apr (3)	_May	_Jun	_Jul	_Aug	_Sep (13)	_Oct (12)	_Nov (10)	_Dec (8)
2007	_Jan	_Feb (1)	_Mar (1)	_Apr	_May	_Jun (5)	_Jul	_Aug (1)	_Sep (4)	_Oct (15)	_Nov	_Dec (1)
2008	_Jan	_Feb (1)	_Mar	_Apr	_May	_Jun	_Jul	_Aug (2)	_Sep (5)	_Oct	_Nov	_Dec
2011	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov (4)	_Dec
2012	_Jan	_Feb	_Mar	_Apr	_May	_Jun (3)	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec

Flat | Threaded

<< < 1 .. 5 6 7 8 > >> (Page 7 of 8)

[Informixdb-cvs] informixdb/ext _informixdb.ec,1.20,1.21

From: Carsten H. <ch...@us...> - 2005-10-27 03:50:18

Update of /cvsroot/informixdb/informixdb/ext
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15869/ext

Modified Files:
	_informixdb.ec 
Log Message:
experimental support for IDS extended types (complex types and UDTs)


Index: _informixdb.ec
===================================================================
RCS file: /cvsroot/informixdb/informixdb/ext/_informixdb.ec,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** _informixdb.ec	27 Oct 2005 03:45:06 -0000	1.20
--- _informixdb.ec	27 Oct 2005 03:50:07 -0000	1.21
***************
*** 942,950 ****
    const char *val = PyString_AS_STRING((PyStringObject*)sitem);
    int n = strlen(val);
!   var->sqltype = CSTRINGTYPE;
!   var->sqldata = malloc(n+1);
!   var->sqllen = n+1;
!   *var->sqlind = 0;
!   memcpy(var->sqldata, val, n+1);
    Py_DECREF(sitem);
    return 1;
--- 942,970 ----
    const char *val = PyString_AS_STRING((PyStringObject*)sitem);
    int n = strlen(val);
!   if (n<32768) {
!     var->sqltype = CSTRINGTYPE;
!     var->sqldata = malloc(n+1);
!     var->sqllen = n+1;
!     *var->sqlind = 0;
!     memcpy(var->sqldata, val, n+1);
!   }
!   else {
!     /* use lvarchar* instead */
!     EXEC SQL BEGIN DECLARE SECTION;
!     lvarchar **data;
!     EXEC SQL END DECLARE SECTION;
!     data = malloc(sizeof(void*));
!     *data = 0;
!     ifx_var_flag(data, 0);
!     ifx_var_alloc(data, n+1);
!     ifx_var_setlen(data, n);
!     ifx_var_setdata(data, (char *)val, n);
!     var->sqltype = SQLUDTVAR;
!     var->sqlxid = XID_LVARCHAR;
!     var->sqldata = *data;
!     var->sqllen  = sizeof(void*);
!     *var->sqlind = 0;
!     free( data );
!   }
    Py_DECREF(sitem);
    return 1;
***************
*** 1117,1121 ****
        break;
      default:
!       var->sqltype = CCHARTYPE;
        break;
  
--- 1137,1144 ----
        break;
      default:
!       if (ISCOMPLEXTYPE(var->sqltype) || ISUDTTYPE(var->sqltype))
!         var->sqltype = CLVCHARPTRTYPE;
!       else
!         var->sqltype = CCHARTYPE;
        break;
  
***************
*** 1139,1144 ****
        loc->loc_mflags = 0;
      }
!     var->sqldata = bufp;
!     bufp += var->sqllen;
  
      if (var->sqltype == CDTIMETYPE) {
--- 1162,1183 ----
        loc->loc_mflags = 0;
      }
!     else if (var->sqltype == CLVCHARPTRTYPE )
!     {
!       exec sql begin declare section;
!       lvarchar **currentlvarcharptr;
!       exec sql end declare section;
! 
!       currentlvarcharptr = malloc(sizeof(void *));
!       *currentlvarcharptr = 0;
!       ifx_var_flag(currentlvarcharptr,1);
! 
!       var->sqlxid = 1;
!       var->sqldata = *currentlvarcharptr;
!       var->sqllen  = sizeof(void *);
!     }
!     else {
!       var->sqldata = bufp;
!       bufp += var->sqllen;
!     }
  
      if (var->sqltype == CDTIMETYPE) {
***************
*** 1510,1513 ****
--- 1549,1570 ----
    } /* case SQLTEXT */
    } /* switch */
+   if (ISCOMPLEXTYPE(type)||ISUDTTYPE(type)) {
+     PyObject *buffer;
+     int lvcharlen = ifx_var_getlen(&data);
+     void *lvcharbuf = ifx_var_getdata(&data);
+     char *b_mem;
+     int b_len;
+ 
+     buffer = PyBuffer_New(lvcharlen);
+ 
+     if (PyObject_AsWriteBuffer(buffer, (void**)&b_mem, &b_len) == -1) {
+       Py_DECREF(buffer);
+       return NULL;
+     }
+ 
+     memcpy(b_mem, lvcharbuf, b_len);
+     ifx_var_dealloc(&data);
+     return buffer;
+   }
    Py_INCREF(Py_None);
    return Py_None;
***************
*** 1581,1584 ****
--- 1638,1644 ----
            }
          }
+         if (da->sqlvar[i].sqltype == SQLUDTVAR) {
+           ifx_var_dealloc((void**)&(da->sqlvar[i].sqldata));
+         }
          free(da->sqlvar[i].sqldata);
        }

[Informixdb-cvs] informixdb/ext _informixdb.ec,1.19,1.20

From: Carsten H. <ch...@us...> - 2005-10-27 03:45:15

Update of /cvsroot/informixdb/informixdb/ext
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14989

Modified Files:
	_informixdb.ec 
Log Message:
This code is unnecessary since we're requiring Python >=2.2 now, and the 'L'
suffix disappeared in Python 1.6


Index: _informixdb.ec
===================================================================
RCS file: /cvsroot/informixdb/informixdb/ext/_informixdb.ec,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** _informixdb.ec	26 Oct 2005 03:02:58 -0000	1.19
--- _informixdb.ec	27 Oct 2005 03:45:06 -0000	1.20
***************
*** 947,954 ****
    *var->sqlind = 0;
    memcpy(var->sqldata, val, n+1);
-   if (PyLong_Check(item)) {
-     /* erase 'L' suffix if present */
-     if (var->sqldata[n-1]=='L') { var->sqldata[n-1] = 0; }
-   }
    Py_DECREF(sitem);
    return 1;
--- 947,950 ----

[Informixdb-cvs] informixdb/ext _informixdb.ec,1.18,1.19

From: Carsten H. <ch...@us...> - 2005-10-26 03:03:09

Update of /cvsroot/informixdb/informixdb/ext
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11915/ext

Modified Files:
	_informixdb.ec 
Log Message:
Binding python bools would result in attempting to bind the strings
'True' or 'False', resulting in conversion error. Thanks to Michael
Husmann for reporting the problem and suggesting the fix.


Index: _informixdb.ec
===================================================================
RCS file: /cvsroot/informixdb/informixdb/ext/_informixdb.ec,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -d -r1.18 -r1.19
*** _informixdb.ec	20 Oct 2005 04:39:01 -0000	1.18
--- _informixdb.ec	26 Oct 2005 03:02:58 -0000	1.19
***************
*** 936,939 ****
--- 936,942 ----
  static int ibindString(struct sqlvar_struct *var, PyObject *item)
  {
+   if PyBool_Check(item) {
+     item = PyNumber_Int(item);
+   }
    PyObject *sitem = PyObject_Str(item);
    const char *val = PyString_AS_STRING((PyStringObject*)sitem);

[Informixdb-cvs] informixdb README,1.6,1.7

From: Carsten H. <ch...@us...> - 2005-10-23 02:33:37

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10916

Modified Files:
	README 
Log Message:
prepare for 2.0 release


Index: README
===================================================================
RCS file: /cvsroot/informixdb/informixdb/README,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** README	19 Oct 2005 13:31:13 -0000	1.6
--- README	23 Oct 2005 02:33:27 -0000	1.7
***************
*** 63,68 ****
  
  A Windows installer for Python 2.4 is available for download at
! http://sourceforge.net/projects/informixdb. Download it and run it to
! install the InformixDB module. Note that you'll need the Informix Client SDK
  to use the InformixDB module.
  
--- 63,68 ----
  
  A Windows installer for Python 2.4 is available for download at
! http://informixdb.sourceforge.net/. Download it and run it to install
! the InformixDB module. Note that you'll need the Informix Client SDK
  to use the InformixDB module.
  
***************
*** 240,246 ****
  1.4      2005-04-11  Carsten Haese
  1.5      2005-09-18  Carsten Haese
! 2.0      TBD         Carsten Haese
  
  --
  Carsten Haese <ch...@us...>
! http://sourceforge.net/projects/informixdb
--- 240,246 ----
  1.4      2005-04-11  Carsten Haese
  1.5      2005-09-18  Carsten Haese
! 2.0      2005-10-22  Carsten Haese
  
  --
  Carsten Haese <ch...@us...>
! http://informixdb.sourceforge.net/

[Informixdb-cvs] informixdb MANIFEST,1.2,1.3

From: Carsten H. <ch...@us...> - 2005-10-23 02:32:55

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10782

Modified Files:
	MANIFEST 
Log Message:
add doc folder to distribution


Index: MANIFEST
===================================================================
RCS file: /cvsroot/informixdb/informixdb/MANIFEST,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** MANIFEST	20 Oct 2005 02:43:54 -0000	1.2
--- MANIFEST	23 Oct 2005 02:32:48 -0000	1.3
***************
*** 9,10 ****
--- 9,15 ----
  tests/dbapi20.py
  tests/testdbapi.py
+ doc/default.css
+ doc/informixdb.css
+ doc/Makefile
+ doc/manual.html
+ doc/manual.txt

[Informixdb-cvs] informixdb/doc Makefile,NONE,1.1

From: Carsten H. <ch...@us...> - 2005-10-23 02:29:03

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10104

Added Files:
	Makefile 
Log Message:
add a convenient Makefile for building the HTML manual


--- NEW FILE: Makefile ---
# use this Makefile to generate HTML documentation from manual.txt
# (requires docutils)
manual.html: manual.txt
	rst2html.py --stylesheet-path=informixdb.css manual.txt >manual.html

[Informixdb-cvs] informixdb/doc manual.txt,1.4,1.5

From: Carsten H. <ch...@us...> - 2005-10-22 18:35:19

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17930

Modified Files:
	manual.txt 
Log Message:
Minor typo fixes and grammatical fixes to Daniel's excellent documentation.
Thanks, Daniel :)


Index: manual.txt
===================================================================
RCS file: /cvsroot/informixdb/informixdb/doc/manual.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** manual.txt	22 Oct 2005 15:21:01 -0000	1.4
--- manual.txt	22 Oct 2005 18:35:06 -0000	1.5
***************
*** 49,53 ****
  forward all operations on the `Connection` object or any of its associated
  `Cursor` objects will raise an `InterfaceError`. A connection will also be
! closed when upon deallocation (this requires all `Cursor` objects which use
  the connection to be closed or deallocated first).
  
--- 49,53 ----
  forward all operations on the `Connection` object or any of its associated
  `Cursor` objects will raise an `InterfaceError`. A connection will also be
! closed upon deallocation (this requires all `Cursor` objects which use
  the connection to be closed or deallocated first).
  
***************
*** 76,80 ****
  
  To pass in arguments for an SQL statement a sequence can be passed as second
! parameter to `execute`. The arguments can then be referenced either by
  ``numeric`` or ``qmark`` style::
  
--- 76,80 ----
  
  To pass in arguments for an SQL statement a sequence can be passed as second
! parameter to `execute`. The arguments can then be referenced either using
  ``numeric`` or ``qmark`` style::
  
***************
*** 85,89 ****
  
  Care must be taken when passing in a single string as argument, since it
! would be interpreted as sequence, which is usually not what is intended::
  
      >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'dagobert')
--- 85,89 ----
  
  Care must be taken when passing in a single string as argument, since it
! would be interpreted as a sequence, which is usually not what is intended::
  
      >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'dagobert')
***************
*** 118,122 ****
    ``1`` for InformixDB.
  
! - ``fetchall()``: Fetches all (remaining) rows and returns them as list.
  
  ::
--- 118,122 ----
    ``1`` for InformixDB.
  
! - ``fetchall()``: Fetches all (remaining) rows and returns them as a list.
  
  ::
***************
*** 161,165 ****
  
  The `type_code` is a textual description of the column type and can be
! evaluated by comparing it with the global type objects defined by the
  `informixdb`-module (see `Database values`_)::
  
--- 161,165 ----
  
  The `type_code` is a textual description of the column type and can be
! evaluated by comparing it to the global type objects defined by the
  `informixdb`-module (see `Database values`_)::
  
***************
*** 183,188 ****
  parameters multiple times. It takes a sequence of parameter-sequences as
  taken by `execute` as its second argument and executes the statement for
! each of the paramaters. Internally insert cursors for batch inserts, which
! can result in a huge performance boost, especially over a network::
  
      >>> cursor.executemany("INSERT INTO names VALUES(:1,:2,:3)",
--- 183,188 ----
  parameters multiple times. It takes a sequence of parameter-sequences as
  taken by `execute` as its second argument and executes the statement for
! each of the parameters. Internally, insert cursors are used for batch inserts,
! which can result in a huge performance boost, especially over a network::
  
      >>> cursor.executemany("INSERT INTO names VALUES(:1,:2,:3)",
***************
*** 193,197 ****
  -------------------
  
! Named Cursor can be created by passing the requested cursor name in as first
  argument to `Connection.cursor`::
  
--- 193,197 ----
  -------------------
  
! Named Cursors can be created by passing the requested cursor name in as first
  argument to `Connection.cursor`::
  
***************
*** 199,203 ****
  
  The returned `Cursor` object will then use this name whenever it declares a
! database cursor. It is important to note that a `Cursor` objects lifetime is
  decoupled from that actual database cursors. Database cursor are created
  whenever a SQL statement that can return a result set is executed (i.e.
--- 199,203 ----
  
  The returned `Cursor` object will then use this name whenever it declares a
! database cursor. It is important to note that a `Cursor` object's lifetime is
  decoupled from that actual database cursors. Database cursor are created
  whenever a SQL statement that can return a result set is executed (i.e.
***************
*** 206,211 ****
  
  The main implication of this is that you cannot use the named `Cursor`
! object to execute statements on the named cursor, as that will destroy the
! database cursor before executing the statement. Instead a second (possibly
  unnamed) `Cursor` is used to execute ``... WHERE CURRENT OF ...``
  statements::
--- 206,211 ----
  
  The main implication of this is that you cannot use the named `Cursor`
! object to execute statements on the named cursor itself, as that will destroy
! the database cursor before executing the statement. Instead, a second (possibly
  unnamed) `Cursor` is used to execute ``... WHERE CURRENT OF ...``
  statements::
***************
*** 240,250 ****
  
  `rowcount`
!     Number of rows effected by the last executed statement, or -1 if no
!     statement was executed or the number is not determinable. InformixDB
!     only provides values for ``DELETE``, ``UPDATE`` and ``INSERT``
      statements.
  
  `sqlerrd`
!     Informix SQL error descriptor (``sqlerrd``) as tuple.
  
  `messages`
--- 240,250 ----
  
  `rowcount`
!     Number of rows affected by the last executed statement, or -1 if no
!     statement was executed or the number can not be determined. InformixDB
!     only provides values for ``DELETE``, ``UPDATE``, and ``INSERT``
      statements.
  
  `sqlerrd`
!     Informix SQL error descriptor (``sqlerrd``) as a tuple.
  
  `messages`
***************
*** 257,261 ****
  ============
  
! When enabled in the underlying database transactions can be used by calling
  `commit` and `rollback` on a `Connection` object. A new transaction will
  automatically be started after the previous one was committed or rolled
--- 257,261 ----
  ============
  
! When enabled in the underlying database, transactions can be used by calling
  `commit` and `rollback` on a `Connection` object. A new transaction will
  automatically be started after the previous one was committed or rolled
***************
*** 301,305 ****
  
  ``NULL``
!     SQL ``NULL`` is represented by Pythons ``None`` when binding parameters
      or returning results.
  
--- 301,305 ----
  
  ``NULL``
!     SQL ``NULL`` is represented by Python's ``None`` when binding parameters
      or returning results.
  
***************
*** 363,367 ****
          Base and catch-all for errors reported by the database.
          `DatabaseError` or subclasses of it are raised whenever a database
!         oparations fails.  When its possible to determine the class of an
          error via ``SQLSTATE``, the more specific error types are raised.
  
--- 363,367 ----
          Base and catch-all for errors reported by the database.
          `DatabaseError` or subclasses of it are raised whenever a database
!         oparations fails.  When it's possible to determine the class of an
          error via ``SQLSTATE``, the more specific error types are raised.
  
***************
*** 396,401 ****
  `Warning`
      Represents a SQL warning (e.g. data truncation). This exception is never
!     actually raised by the default error handler. By default warnings are
!     only reported via the `Connection` or `Cursor` objects `messages`
      attribute (see `Advanced error handling`_).
  
--- 396,401 ----
  `Warning`
      Represents a SQL warning (e.g. data truncation). This exception is never
!     actually raised by the default error handler. By default, warnings are
!     only reported via the `Connection` or `Cursor` object's `messages`
      attribute (see `Advanced error handling`_).
  
***************
*** 430,434 ****
      Sequence of all diagnostic messages reported by Informix where each item
      is a dictionary with keys ``'message'`` for a text representation of the
!     error and ``'sqlstate'`` for the corresponding SQLSTATE value.
  
  Advanced error handling
--- 430,434 ----
      Sequence of all diagnostic messages reported by Informix where each item
      is a dictionary with keys ``'message'`` for a text representation of the
!     message and ``'sqlstate'`` for the corresponding SQLSTATE value.
  
  Advanced error handling
***************
*** 461,475 ****
  - The `Cursor` or `Connection` objects `errorhandler` attribute is checked
    to see if it is set.
! - If a `errorhandler` is available it is invoked with `connection`,
    `cursor`, `errorclass` and `errorvalue` as its arguments. The error
!   handler might raise an exception or return in which case execution is
    continued.
! - If no `errorhandler` is available the built in error handler is invoked.
    A  ``(errorclass, errorvalue)`` tuple is appended to the `Cursor` or
!   `Connection` objects messages attribute and if the error is an actual
!   error (i.e. not of type `Warning`) an exception is raised. 
  
  
  
! .. _InformixDB on Sourceforge: http://www.sourceforge.net/projects/informixdb
  .. [#pep249] http://www.python.org/peps/pep-0249.html
--- 461,475 ----
  - The `Cursor` or `Connection` objects `errorhandler` attribute is checked
    to see if it is set.
! - If an `errorhandler` is available, it is invoked with `connection`,
    `cursor`, `errorclass` and `errorvalue` as its arguments. The error
!   handler might raise an exception or return, in which case execution is
    continued.
! - If no `errorhandler` is available, the built in error handler is invoked.
    A  ``(errorclass, errorvalue)`` tuple is appended to the `Cursor` or
!   `Connection` object's messages attribute, and if the error is an actual
!   error (i.e. not of type `Warning`), an exception is raised. 
  
  
  
! .. _InformixDB on Sourceforge: http://informixdb.sourceforge.net/
  .. [#pep249] http://www.python.org/peps/pep-0249.html

[Informixdb-cvs] informixdb/doc informixdb.css,1.2,1.3 manual.txt,1.3,1.4

From: Daniel S. <da...@us...> - 2005-10-22 15:21:09

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1730

Modified Files:
	informixdb.css manual.txt 
Log Message:
documentation: used better suited 'note' directive for notes instead of field


Index: manual.txt
===================================================================
RCS file: /cvsroot/informixdb/informixdb/doc/manual.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** manual.txt	22 Oct 2005 14:26:05 -0000	1.3
--- manual.txt	22 Oct 2005 15:21:01 -0000	1.4
***************
*** 68,74 ****
      >>> cursor.callproc('lower')
  
! :Note: It is also possible to call a stored procedure by issuing a ``EXECUTE
!        PROCEDURE ...`` statement with `execute`, but `callproc` should be
!        used where possible for standards compatibility.
  
  Binding parameters
--- 68,74 ----
      >>> cursor.callproc('lower')
  
! .. note:: It is also possible to call a stored procedure by issuing a
!           ``EXECUTE PROCEDURE ...`` statement with `execute`, but `callproc`
!           should be used where possible for standards compatibility.
  
  Binding parameters
***************
*** 335,347 ****
      1
  
! :Note: InformixDB uses the `datetime` module to represent date, time and
!        timestamp values. This module is part of the standard library since
!        Python 2.3 and is automatically installed by InformixDB for Python 2.2.
  
! :Note: The ``FRAC`` part of Informix ``DATETIME`` fields is mapped to
!        `datetime.microseconds` but the precision is limited to a maximum of
!        10 microseconds (or less, depending on how the field is defined in
!        the database), due to the limited precision of fractional datetimes
!        in Informix.
  
  Error handling
--- 335,348 ----
      1
  
! .. note:: InformixDB uses the `datetime` module to represent date, time and
!           timestamp values. This module is part of the standard library
!           since Python 2.3 and is automatically installed by InformixDB for
!           Python 2.2.
  
! .. note:: The ``FRAC`` part of Informix ``DATETIME`` fields is mapped to
!           `datetime.microseconds` but the precision is limited to a maximum
!           of 10 microseconds (or less, depending on how the field is defined
!           in the database), due to the limited precision of fractional
!           datetimes in Informix.
  
  Error handling

Index: informixdb.css
===================================================================
RCS file: /cvsroot/informixdb/informixdb/doc/informixdb.css,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** informixdb.css	22 Oct 2005 14:07:55 -0000	1.2
--- informixdb.css	22 Oct 2005 15:21:01 -0000	1.3
***************
*** 14,27 ****
  }
  
! table.field-list
! {
!     background: yellow; 
!     margin: 0.5em 1em;
!     border: 1px solid black;
! }
! 
! table.docutils th.field-name, table.docutils td.field-body
  {
!     padding: 0.3em 0.5em;
!     background: #ffff77;
  }
--- 14,22 ----
  }
  
! div.note
  {
!    margin: 0.5em 2em; 
!    padding: 0.5em 0.5em;
!    background: #ffff77;
!    border: 1px solid black;
  }

[Informixdb-cvs] informixdb/doc manual.txt,1.2,1.3

From: Daniel S. <da...@us...> - 2005-10-22 14:26:16

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24085

Modified Files:
	manual.txt 
Log Message:
document NULL/None in 'Database values'. documentation should be complete now


Index: manual.txt
===================================================================
RCS file: /cvsroot/informixdb/informixdb/doc/manual.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** manual.txt	22 Oct 2005 14:07:55 -0000	1.2
--- manual.txt	22 Oct 2005 14:26:05 -0000	1.3
***************
*** 300,303 ****
--- 300,307 ----
      database independent time or timestamp (i.e. ``DATETIME``) values.
  
+ ``NULL``
+     SQL ``NULL`` is represented by Pythons ``None`` when binding parameters
+     or returning results.
+ 
  Furthermore there are a number of objects defined by the module which can be
  used to compare database column types as they appear in `Cursor.description`

[Informixdb-cvs] informixdb/doc informixdb.css,1.1,1.2 manual.txt,1.1,1.2

From: Daniel S. <da...@us...> - 2005-10-22 14:08:04

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19850

Modified Files:
	informixdb.css manual.txt 
Log Message:
wrote documentation


Index: manual.txt
===================================================================
RCS file: /cvsroot/informixdb/informixdb/doc/manual.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** manual.txt	20 Oct 2005 21:02:16 -0000	1.1
--- manual.txt	22 Oct 2005 14:07:55 -0000	1.2
***************
*** 5,10 ****
  :Authors: Daniel Smertnig
  :Version: informixdb 2.0
! :Date: 2005-10-19
! :Sourceforge: `InformixDB on Sourceforge`_
  
  .. contents:: InformixDB
--- 5,10 ----
  :Authors: Daniel Smertnig
  :Version: informixdb 2.0
! :Date: 2005-10-22
! :Homepage: `InformixDB on Sourceforge`_
  
  .. contents:: InformixDB
***************
*** 13,20 ****
  ============
  
! InformixDB is a Python extension module that allows you to connect to an
  Informix database via Python's Database API 2.0 [#pep249]_.
  
! Here's a quick example to get you started::
  
      >>> import informixdb
--- 13,20 ----
  ============
  
! InformixDB is a Python extension module that provides a way to connect to an
  Informix database via Python's Database API 2.0 [#pep249]_.
  
! Here's a quick example to get started::
  
      >>> import informixdb
***************
*** 28,32 ****
  ==========
  
! To do anything useful with InformixDB you must connect to a database. This
  is accomplished by calling `informixdb.connect`::
  
--- 28,32 ----
  ==========
  
! To do anything useful with InformixDB one must connect to a database. This
  is accomplished by calling `informixdb.connect`::
  
***************
*** 41,56 ****
  an optional `user` and a corresponding password.
  
! If the `dsn` doesn't include a servername the value of ``$INFORMIXSERVER``
! is used. When connecting without specifying the name of the database no
! database will be selected. This is useful for setting up a new database from
! within InformixDB.
  
! :TODO: document Connection.close, Cursor.close somewhere
  
! Executing SQL Statements
  ========================
  
! To actually execute a SQL statement you have to create a `Cursor` object
! using `Connection.cursor`::
  
      >>> cursor = conn.cursor()
--- 41,60 ----
  an optional `user` and a corresponding password.
  
! If the `dsn` doesn't include a servername the value of the environment
! variable ``INFORMIXSERVER`` is used. When connecting without specifying the
! name of the database no database will be selected. This is useful for
! setting up a new database from within InformixDB.
  
! A `Connection` can be closed by calling its `close` method. From that point
! forward all operations on the `Connection` object or any of its associated
! `Cursor` objects will raise an `InterfaceError`. A connection will also be
! closed when upon deallocation (this requires all `Cursor` objects which use
! the connection to be closed or deallocated first).
  
! Executing SQL statements
  ========================
  
! To actually execute a SQL statement a `Cursor` object must be created by
! calling `Connection.cursor`::
  
      >>> cursor = conn.cursor()
***************
*** 64,73 ****
      >>> cursor.callproc('lower')
  
  Binding parameters
  ------------------
  
! To pass in arguments for an SQL statement a sequence can be passed in as second
! parameter. The arguments can then be referenced either by ``numeric`` or
! ``qmark`` style::
  
      >>> cursor.execute('INSERT INTO names VALUES(:1,:2,:3)', ('some', 'body', 56))
--- 68,81 ----
      >>> cursor.callproc('lower')
  
+ :Note: It is also possible to call a stored procedure by issuing a ``EXECUTE
+        PROCEDURE ...`` statement with `execute`, but `callproc` should be
+        used where possible for standards compatibility.
+ 
  Binding parameters
  ------------------
  
! To pass in arguments for an SQL statement a sequence can be passed as second
! parameter to `execute`. The arguments can then be referenced either by
! ``numeric`` or ``qmark`` style::
  
      >>> cursor.execute('INSERT INTO names VALUES(:1,:2,:3)', ('some', 'body', 56))
***************
*** 76,81 ****
      1
  
! Be careful when trying to pass in a single string as argument, since it
! would be interpreted as sequence, which is usually not what you want::
  
      >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'dagobert')
--- 84,89 ----
      1
  
! Care must be taken when passing in a single string as argument, since it
! would be interpreted as sequence, which is usually not what is intended::
  
      >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'dagobert')
***************
*** 85,93 ****
      >>> cursor.execute('SELECT * FROM names WHERE first=:1', ('dagobert',)
  
! As you can see InformixDB will catch most of these errors since it requires
! the number of arguments to match the number of parameters exactly.
  
  Calling stored procedures with arguments is supported in a similiar way,
! though you don't have to specify the arguments explicitely::
  
      >>> cursor.callproc('lower', ('FOO',))
--- 93,101 ----
      >>> cursor.execute('SELECT * FROM names WHERE first=:1', ('dagobert',)
  
! InformixDB will catch most of these errors since it requires the number of
! arguments to match the number of parameters exactly.
  
  Calling stored procedures with arguments is supported in a similiar way,
! except that no placeholders have to be specified::
  
      >>> cursor.callproc('lower', ('FOO',))
***************
*** 97,114 ****
  
  To retrieve the results of a previously executed SQL statement or stored
! procedure call one of `fetchone`, `fetchmany` or `fetchall` on the `Cursor`:
  
! - ``cursor.fetchone()``: Returns the next row of the result set or ``None``
!   if no more rows are available.
  
! - ``cursor.fetchmany([size=Cursor.arraysize])``: Fetches up to `size` rows
!   (less if there are no more rows) and returns them as a list. An empty list
!   is returned when no (more) rows are available.
  
    If `size` is not specified `Cursor.arraysize` is used, which defaults to
    ``1`` for InformixDB.
  
! - ``cursor.fetchall()``: Fetches all (remaining) rows and returns them as
!   list.
  
  ::
--- 105,122 ----
  
  To retrieve the results of a previously executed SQL statement or stored
! procedure `Cursor` objects provide tho `fetchone`, `fetchmany` and
! `fetchall` methods:
  
! - ``fetchone()``: Returns the next row of the result set or ``None`` if no
!   more rows are available.
  
! - ``fetchmany([size=Cursor.arraysize])``: Fetches up to `size` rows (less if
!   there are no more rows) and returns them as a list. An empty list is
!   returned when no (more) rows are available.
  
    If `size` is not specified `Cursor.arraysize` is used, which defaults to
    ``1`` for InformixDB.
  
! - ``fetchall()``: Fetches all (remaining) rows and returns them as list.
  
  ::
***************
*** 116,123 ****
      >>> cursor.execute("SELECT * FROM names")
      >>> cursor.fetchall()
!     [('donald', 'duck', 34), ('mickey', 'mouse', 23), ('dagobert', 'duck', 77), ('some', 'body', 56)]
  
! If you don't mind using an extension to the DB-API 2.0 specification you can
! also iterate over `Cursor` objects::
  
      >>> cursor.execute("SELECT * FROM names")
--- 124,132 ----
      >>> cursor.execute("SELECT * FROM names")
      >>> cursor.fetchall()
!     [('donald', 'duck', 34), ('mickey', 'mouse', 23),
!      ('dagobert', 'duck', 77), ('some', 'body', 56)]
  
! As an extension to the DB-API 2.0 specification InformixDB `Cursor` objects
! can also be used as iterators::
  
      >>> cursor.execute("SELECT * FROM names")
***************
*** 131,137 ****
      >>>
  
! Normally rows are returned as tuples, but you can also request that
! dictionaries should be returned instead. This must be specified when the
! `Cursor` is created::
  
      >>> dictcur = conn.cursor(rowformat = informixdb.ROW_AS_DICT)
--- 140,145 ----
      >>>
  
! Normally rows are returned as tuples, but optionally dictionaries can be
! returned. This must be specified when the `Cursor` is created::
  
      >>> dictcur = conn.cursor(rowformat = informixdb.ROW_AS_DICT)
***************
*** 140,143 ****
--- 148,176 ----
      {'age': 34, 'last': 'duck', 'first': 'donald'}
  
+ Describing result sets
+ ,,,,,,,,,,,,,,,,,,,,,,
+ 
+ Whenever a statement which returns a result set is executed a description of
+ the columns returned is made available in the `Cursor` objects `description`
+ attribute.
+ 
+ It is a sequence of 7-tuples with one tuple for each returned column. Each
+ tuple consists of `name`, `type_code`, `display_size`, `internal_size`,
+ `precision`, `scale` and `null_ok` values (`precision` and `scale` are
+ currently always set to `None` by InformixDB).
+ 
+ The `type_code` is a textual description of the column type and can be
+ evaluated by comparing it with the global type objects defined by the
+ `informixdb`-module (see `Database values`_)::
+ 
+     >>> cursor.execute('SELECT * FROM names')
+     >>> cursor.description
+     (('first', 'char', 25, 25, None, None, 1),('last', 'char', 50, 50,
+     None, None, 1), ('age', 'integer', 4, 4, None, None, 1))
+     >>> cursor.description[0][1] == informixdb.STRING
+     1
+     >>> cursor.description[0][1] == informixdb.NUMBER
+     0
+ 
  Fast execution of batch statements
  ----------------------------------
***************
*** 147,155 ****
  only once. 
  
! You can also use `executemany`, which takes a sequence of
! parameter-sequences as taken by `execute` and executes the statement with
! each of the parameters. `executemany` will internally use insert cursors for
! batch inserts, which can result in a huge performance boost, especially over
! a network::
  
      >>> cursor.executemany("INSERT INTO names VALUES(:1,:2,:3)",
--- 180,188 ----
  only once. 
  
! `executemany` can be used to execute the same statement with different
! parameters multiple times. It takes a sequence of parameter-sequences as
! taken by `execute` as its second argument and executes the statement for
! each of the paramaters. Internally insert cursors for batch inserts, which
! can result in a huge performance boost, especially over a network::
  
      >>> cursor.executemany("INSERT INTO names VALUES(:1,:2,:3)",
***************
*** 157,209 ****
      ... )
  
! Using named Cursors
  -------------------
  
! :TODO: describe named cursor and how to use them
  
  
! TODO stuff
! -----------
  
! :TODO: document Cursor attributes somewhere
  
! :TODO: document how Cursor.description can be used & how it relates to result
!        sets
  
  Transactions
  ============
  
! :TODO: document commit / rollback
  
! Database Values
  ===============
  
! :TODO: how values are bound
  
! :TODO: how values can be constructed
  
! InformixDB uses the `datetime` module to represent date, time and timestamp
! values. This module is part of the standard library since Python 2.3 and is
! automatically installed by InformixDB for Python 2.2.
  
! Take care that while the ``FRAC`` part of Informix ``DATETIME`` fields is
! mapped to `datetime.microseconds` the precision is limited to a maximum of
! 10 microseconds, due to the limited precision of fractional datetimes in
! Informix.
  
! Error Handling
  ==============
  
! :TODO: describe exception types
  
! Interpreting Errors
! -------------------
  
! :TODO: attributes of DatabaseError & Warning
  
- Customizing Error Handling
- --------------------------
  
- :TODO: errorhandler & messages
  
  .. _InformixDB on Sourceforge: http://www.sourceforge.net/projects/informixdb
--- 190,469 ----
      ... )
  
! Using named cursors
  -------------------
  
! Named Cursor can be created by passing the requested cursor name in as first
! argument to `Connection.cursor`::
  
+     >>> namcursor = conn.cursor('foo')
  
! The returned `Cursor` object will then use this name whenever it declares a
! database cursor. It is important to note that a `Cursor` objects lifetime is
! decoupled from that actual database cursors. Database cursor are created
! whenever a SQL statement that can return a result set is executed (i.e.
! ``SELECT`` and ``EXECUTE PROCEDURE``) and destroyed when the `Cursor` is
! closed or another statement is executed with the same `Cursor` object.
  
! The main implication of this is that you cannot use the named `Cursor`
! object to execute statements on the named cursor, as that will destroy the
! database cursor before executing the statement. Instead a second (possibly
! unnamed) `Cursor` is used to execute ``... WHERE CURRENT OF ...``
! statements::
  
!     >>> namcursor = conn.cursor('foo')
!     >>> cursor = conn.cursor()
!     >>> namcursor.execute('SELECT * FROM names FOR UPDATE')
!     >>> namcursor.fetchone()
!     ('donald', 'duck', 34)
!     >>> cursor.execute("UPDATE names SET first='notdonald' WHERE CURRENT OF foo")
!     1
!     >>> cursor.execute("SELECT * FROM names")
!     >>> cursor.fetchone()
!     ('notdonald', 'duck', 34)
! 
! Cursor attributes
! -----------------
! 
! `Cursor` objects expose a few attributes, most of which provide extra
! information about executed statements:
! 
! `arraysize`
!     Default `size` to be used for `fetchmany`, defaults to 1.
! 
! `connection`
!     The `Connection` object associated with this `Cursor`.
! 
! `description`
!     Description of the result set returned by the currently prepared
!     statement. See `Describing result sets`_ for information on how to use
!     this attribute.
! 
! `rowcount`
!     Number of rows effected by the last executed statement, or -1 if no
!     statement was executed or the number is not determinable. InformixDB
!     only provides values for ``DELETE``, ``UPDATE`` and ``INSERT``
!     statements.
! 
! `sqlerrd`
!     Informix SQL error descriptor (``sqlerrd``) as tuple.
! 
! `messages`
!     See `Advanced error handling`_ on how to use `errorhandler` and `messages`.
! 
! `errorhandler`
!     See `Advanced error handling`_ on how to use `errorhandler` and `messages`.
  
  Transactions
  ============
  
! When enabled in the underlying database transactions can be used by calling
! `commit` and `rollback` on a `Connection` object. A new transaction will
! automatically be started after the previous one was committed or rolled
! back.
  
! Before the connection to the database is closed an implicit rollback is
! performed.
! 
! When transactions are disabled in the database, `commit` becomes a no-op and
! `rollback` raises a `NotSupportedError` when called.
! 
! Database values
  ===============
  
! The following describes how database values are mapped to Python objects by
! InformixDB:
  
! ``CHAR``, ``VARCHAR``, ``NCHAR``, ``NVARCHAR``, ``LVARCHAR``
!     `string`
  
! ``FLOAT``, ``SMALLFLOAT``, ``DECIMAL``, ``MONEY``
!     `float`
  
! ``SMALLINT``, ``INT``, ``SERIAL``
!     `int`
  
! ``BYTE``, ``TEXT``
!     `buffer`; The ``informixdb.Binary(string)`` should be used to create
!     database independent large object values.
! 
! ``DATE``
!     `datettime.date`; ``informixdb.Date(year,month,day)`` or
!     ``informixdb.DateFromTicks(ticks)`` should be used to create database
!     independent date values.
! 
! ``DATETIME``
!     `datetime.datetime`;
!     ``informixdb.Time(hour,minute,second[,microsecond=0])``,
!     ``informixdb.TimeFromTicks(ticks)``,
!     ``informixdb.Timestamp(year,month,day,hour=0,minute=0,second=0[,microsecond=0]``
!     or ``informixdb.TimestampFromTicks(ticks)`` should be used to create
!     database independent time or timestamp (i.e. ``DATETIME``) values.
! 
! Furthermore there are a number of objects defined by the module which can be
! used to compare database column types as they appear in `Cursor.description`
! against well-known types in a database independent manner:
! 
! `informixdb.STRING`
!     Compares equal to any string based types.
! 
! `informixdb.BINARY`
!     Compares equal to long/binary types (``BYTE`` and ``TEXT``).
! 
! `informixdb.NUMBER`
!     Compares equal to any numeric types.
! 
! `informixdb.DATETIME`
!     Compares equal to any date, time or datetime types.
! 
! `informixdb.ROWID`
!     Compares equal to rowid types (i.e. ``SERIAL``).
! 
! They are used like this, except of course that the actual column types would
! come from `Cursor.description`::
! 
!     >>> informixdb.STRING == 'char'
!     1
!     >>> informixdb.STRING == 'integer'
!     0
!     >>> informixdb.NUMBER == 'integer'
!     1
!     >>> informixdb.NUMBER == 'decimal'
!     1
! 
! :Note: InformixDB uses the `datetime` module to represent date, time and
!        timestamp values. This module is part of the standard library since
!        Python 2.3 and is automatically installed by InformixDB for Python 2.2.
! 
! :Note: The ``FRAC`` part of Informix ``DATETIME`` fields is mapped to
!        `datetime.microseconds` but the precision is limited to a maximum of
!        10 microseconds (or less, depending on how the field is defined in
!        the database), due to the limited precision of fractional datetimes
!        in Informix.
! 
! Error handling
  ==============
  
! InformixDB defines a number of exception types derived from `StandardError`
! to report error conditions:
  
! `Error`
!     Base for all InformixDB errors.
  
!     `InterfaceError`
!         Error in the database interface itself. This is currently raised
!         when trying to used closed `Cursor` or `Connection` objects or when
!         an internal date/time conversion error occurs.
! 
!     `DatabaseError`
!         Base and catch-all for errors reported by the database.
!         `DatabaseError` or subclasses of it are raised whenever a database
!         oparations fails.  When its possible to determine the class of an
!         error via ``SQLSTATE``, the more specific error types are raised.
! 
!         `DataError`
!             Error due to the processed data. E.g. a division by zero or
!             when a numeric value is out of range.
! 
!         `OperationalError`
!             Operational database errors that aren't necessarily under the
!             programmer's control, e.g. connection problems, permission
!             denied or out of memory conditions.
! 
!         `IntegrityError`
!             An integrity constraint would be violated.
! 
!         `InternalError`
!             An error internal to the database, e.g. invalid cursor or
!             transaction states.
! 
!         `ProgrammingError`
!             An error caused by the program. Typically raised when an invalid
!             table is referenced, a syntax error occurs or a SQL statement is
!             invalid.
! 
!         `NotSupportedError`
!             A operation or method is not supported by the database. Raised
!             when trying to invoke `rollback` on a database that doesn't
!             support transactions or when the database doesn't support a
!             particular feature (e.g. ``BYTE/TEXT`` or ``VARCHAR`` on
!             Informix SE).
! 
! `Warning`
!     Represents a SQL warning (e.g. data truncation). This exception is never
!     actually raised by the default error handler. By default warnings are
!     only reported via the `Connection` or `Cursor` objects `messages`
!     attribute (see `Advanced error handling`_).
! 
! These exception types are accessible as attributes of the
! `informixdb`-module or `Connection` objects.
! 
! `DatabaseError` and `Warning` provide a number of useful attributes with
! information about the underlying SQL error::
! 
!     >>> try:
!     ...     informixdb.connect('nonexisting')
!     ... except informixdb.DatabaseError, e:
!     ...     print e
!     ...     print e.action, e.sqlcode, e.diagnostics
!     ...
!     SQLCODE -329 in CONNECT:
!     IX000: Database not found or no system permission.
!     IX000: No such file or directory
! 
!     CONNECT -329 [ {'message': 'Database not found or no system permission.',
!     'sqlstate': 'IX000'}, {'message': 'No such file or directory',
!     'sqlstate': 'IX000'}]
! 
! `action`
!     The ESQL/C statement which was executed by InformixDB when the error was
!     encountered.
! 
! `sqlcode`
!     Value of Informix' SQLCODE.
! 
! `diagnostics`
!     Sequence of all diagnostic messages reported by Informix where each item
!     is a dictionary with keys ``'message'`` for a text representation of the
!     error and ``'sqlstate'`` for the corresponding SQLSTATE value.
! 
! Advanced error handling
! -----------------------
! 
! `Connection` and `Cursor` objects both have `errorhandler` and `messages`
! attributes which are used for error handling.
! 
! `messages`
!     A list of ``(exception_class, exception_value)`` tuples for all errors
!     and warnings generated by the database relating to this `Cursor` or
!     `Connection`. This list is automatically cleared prior to execution of
!     any `Cursor` or `Connection` methods except for the `fetch*` methods.
! 
! `errorhandler`
!     A Python callable of the form ``errorhandler(connection, cursor,
!     errorclass, errorvalue)`` which is called for all database warnings and
!     errors relating to this `Cursor` or `Connection`. The default (if this
!     is `None`) is to append the error/warning to the `messages` list and
!     raise an exception for errors.
! 
!     This attribute is inherited from the associated `Connection` by `Cursor`
!     objects when they are created.
! 
! When a database error occurs in InformixDB it is basically handled like this
! (which path is followed depends on whether the error occurs during execution
! of a `Connection` or `Cursor` method):
! 
! - The exception class and exception value is determined.
! - The `Cursor` or `Connection` objects `errorhandler` attribute is checked
!   to see if it is set.
! - If a `errorhandler` is available it is invoked with `connection`,
!   `cursor`, `errorclass` and `errorvalue` as its arguments. The error
!   handler might raise an exception or return in which case execution is
!   continued.
! - If no `errorhandler` is available the built in error handler is invoked.
!   A  ``(errorclass, errorvalue)`` tuple is appended to the `Cursor` or
!   `Connection` objects messages attribute and if the error is an actual
!   error (i.e. not of type `Warning`) an exception is raised. 
  
  
  
  .. _InformixDB on Sourceforge: http://www.sourceforge.net/projects/informixdb

Index: informixdb.css
===================================================================
RCS file: /cvsroot/informixdb/informixdb/doc/informixdb.css,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** informixdb.css	20 Oct 2005 21:02:16 -0000	1.1
--- informixdb.css	22 Oct 2005 14:07:55 -0000	1.2
***************
*** 3,14 ****
  h1.title
  { 
!     background: #408060; 
      color: white; 
      padding: 3pt 0;
!   /*  border-bottom: 0px; */
  }
  
! /*h1, h2
  {
!     border-bottom: 1px dashed #408060;
! }*/
--- 3,27 ----
  h1.title
  { 
!     background: #448866; 
      color: white; 
      padding: 3pt 0;
!     border-bottom: 0px;
  }
  
! h1, h2, h3
  {
!     border-bottom: 1px dashed #448866;
! }
! 
! table.field-list
! {
!     background: yellow; 
!     margin: 0.5em 1em;
!     border: 1px solid black;
! }
! 
! table.docutils th.field-name, table.docutils td.field-body
! {
!     padding: 0.3em 0.5em;
!     background: #ffff77;
! }

[Informixdb-cvs] informixdb/doc default.css,NONE,1.1 informixdb.css,NONE,1.1 manual.txt,NONE,1.1

From: Daniel S. <da...@us...> - 2005-10-20 21:02:25

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17650

Added Files:
	default.css informixdb.css manual.txt 
Log Message:
start of external (non-docstring) documentation


--- NEW FILE: manual.txt ---
==========================
 InformixDB Documentation
==========================

:Authors: Daniel Smertnig
:Version: informixdb 2.0
:Date: 2005-10-19
:Sourceforge: `InformixDB on Sourceforge`_

.. contents:: InformixDB

Introduction
============

InformixDB is a Python extension module that allows you to connect to an
Informix database via Python's Database API 2.0 [#pep249]_.

Here's a quick example to get you started::

    >>> import informixdb
    >>> conn = informixdb.connect('mydatabase')
    >>> cursor = conn.cursor()
    >>> cursor.execute("SELECT * FROM names")
    >>> cursor.fetchall()
    [('donald', 'duck', 34), ('mickey', 'mouse', 23)]

Connecting
==========

To do anything useful with InformixDB you must connect to a database. This
is accomplished by calling `informixdb.connect`::

    >>> import informixdb
    >>> conn = informixdb.connect('db@daniel', user='me', password='something')
    >>> conn
    <_informixdb.Connection object at 0xb7d08e90>

`informixdb.connect` takes three arguments: A `dsn` which identifies the
database and server to connect to, as recognized by ESQL's ``CONNECT``
statement (e.g. ``'database@server'``, ``'database'``, ``'@server'``) plus
an optional `user` and a corresponding password.

If the `dsn` doesn't include a servername the value of ``$INFORMIXSERVER``
is used. When connecting without specifying the name of the database no
database will be selected. This is useful for setting up a new database from
within InformixDB.

:TODO: document Connection.close, Cursor.close somewhere

Executing SQL Statements
========================

To actually execute a SQL statement you have to create a `Cursor` object
using `Connection.cursor`::

    >>> cursor = conn.cursor()
    >>> cursor
    <_informixdb.Cursor object at 0xb7d84440>

This Cursor object can then be used to execute SQL statements or to call
stored procedures::

    >>> cursor.execute('SELECT * FROM NAMES')
    >>> cursor.callproc('lower')

Binding parameters
------------------

To pass in arguments for an SQL statement a sequence can be passed in as second
parameter. The arguments can then be referenced either by ``numeric`` or
``qmark`` style::

    >>> cursor.execute('INSERT INTO names VALUES(:1,:2,:3)', ('some', 'body', 56))
    1
    >>> cursor.execute('INSERT INTO names VALUES(?,?,?)', ('dagobert', 'duck', 77))
    1

Be careful when trying to pass in a single string as argument, since it
would be interpreted as sequence, which is usually not what you want::

    >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'dagobert')
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    _informixdb.InterfaceError: too many actual parameters
    >>> cursor.execute('SELECT * FROM names WHERE first=:1', ('dagobert',)

As you can see InformixDB will catch most of these errors since it requires
the number of arguments to match the number of parameters exactly.

Calling stored procedures with arguments is supported in a similiar way,
though you don't have to specify the arguments explicitely::

    >>> cursor.callproc('lower', ('FOO',))

Getting results
---------------

To retrieve the results of a previously executed SQL statement or stored
procedure call one of `fetchone`, `fetchmany` or `fetchall` on the `Cursor`:

- ``cursor.fetchone()``: Returns the next row of the result set or ``None``
  if no more rows are available.

- ``cursor.fetchmany([size=Cursor.arraysize])``: Fetches up to `size` rows
  (less if there are no more rows) and returns them as a list. An empty list
  is returned when no (more) rows are available.

  If `size` is not specified `Cursor.arraysize` is used, which defaults to
  ``1`` for InformixDB.

- ``cursor.fetchall()``: Fetches all (remaining) rows and returns them as
  list.

::

    >>> cursor.execute("SELECT * FROM names")
    >>> cursor.fetchall()
    [('donald', 'duck', 34), ('mickey', 'mouse', 23), ('dagobert', 'duck', 77), ('some', 'body', 56)]

If you don't mind using an extension to the DB-API 2.0 specification you can
also iterate over `Cursor` objects::

    >>> cursor.execute("SELECT * FROM names")
    >>> for row in cursor:
    ...     print "%s %s (%d)" % row
    ...
    donald duck (34)
    mickey mouse (23)
    dagobert duck (77)
    some body (56)
    >>>

Normally rows are returned as tuples, but you can also request that
dictionaries should be returned instead. This must be specified when the
`Cursor` is created::

    >>> dictcur = conn.cursor(rowformat = informixdb.ROW_AS_DICT)
    >>> dictcur.execute("SELECT * FROM names")
    >>> dictcur.fetchone()
    {'age': 34, 'last': 'duck', 'first': 'donald'}

Fast execution of batch statements
----------------------------------

When `execute` is called multiple times with the same SQL statement object
on the same Cursor object but different arguments the statement is prepared
only once. 

You can also use `executemany`, which takes a sequence of
parameter-sequences as taken by `execute` and executes the statement with
each of the parameters. `executemany` will internally use insert cursors for
batch inserts, which can result in a huge performance boost, especially over
a network::

    >>> cursor.executemany("INSERT INTO names VALUES(:1,:2,:3)",
    ...     [ ('no', 'more', 12), ('names', 'left', 34) ]
    ... )

Using named Cursors
-------------------

:TODO: describe named cursor and how to use them


TODO stuff
-----------

:TODO: document Cursor attributes somewhere

:TODO: document how Cursor.description can be used & how it relates to result
       sets

Transactions
============

:TODO: document commit / rollback

Database Values
===============

:TODO: how values are bound

:TODO: how values can be constructed

InformixDB uses the `datetime` module to represent date, time and timestamp
values. This module is part of the standard library since Python 2.3 and is
automatically installed by InformixDB for Python 2.2.

Take care that while the ``FRAC`` part of Informix ``DATETIME`` fields is
mapped to `datetime.microseconds` the precision is limited to a maximum of
10 microseconds, due to the limited precision of fractional datetimes in
Informix.

Error Handling
==============

:TODO: describe exception types

Interpreting Errors
-------------------

:TODO: attributes of DatabaseError & Warning

Customizing Error Handling
--------------------------

:TODO: errorhandler & messages

.. _InformixDB on Sourceforge: http://www.sourceforge.net/projects/informixdb
.. [#pep249] http://www.python.org/peps/pep-0249.html

--- NEW FILE: informixdb.css ---
@import url(default.css);

h1.title
{ 
    background: #408060; 
    color: white; 
    padding: 3pt 0;
  /*  border-bottom: 0px; */
}

/*h1, h2
{
    border-bottom: 1px dashed #408060;
}*/

--- NEW FILE: default.css ---
/*
:Author: David Goodger
:Contact: go...@us...
:Date: $Date: 2005/10/20 21:02:16 $
:Version: $Revision: 1.1 $
:Copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/

/* "! important" is used here to override other ``margin-top`` and
   ``margin-bottom`` styles that are later in the stylesheet or 
   more specific.  See http://www.w3.org/TR/CSS1#the-cascade */
.first {
  margin-top: 0 ! important }

.last, .with-subtitle {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dl.docutils dd {
  margin-bottom: 0.5em }

/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
  font-weight: bold }
*/

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

/* Uncomment (and remove this text!) to get reduced vertical space in
   compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
  margin-bottom: 0.5em }

div.compound .compound-last, div.compound .compound-middle {
  margin-top: 0.5em }
*/

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
  margin-top: 0.4em }

h1.title {
  text-align: center }

h2.subtitle {
  text-align: center }

hr.docutils {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee }

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

span.section-subtitle {
  /* font-size relative to parent (<h#> element) */
  font-size: 80% }

table.citation {
  border-left: solid thin gray }

table.docinfo {
  margin: 2em 4em }

table.docutils {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.footnote {
  border-left: solid thin black }

table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

table.docutils th.field-name, table.docinfo th.docinfo-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap ;
  padding-left: 0 }

h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
  font-size: 100% }

tt.docutils {
  background-color: #eeeeee }

ul.auto-toc {
  list-style-type: none }

[Informixdb-cvs] informixdb/doc - New directory

From: Daniel S. <da...@us...> - 2005-10-20 20:54:26

Update of /cvsroot/informixdb/informixdb/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16004/doc

Log Message:
Directory /cvsroot/informixdb/informixdb/doc added to the repository

[Informixdb-cvs] informixdb/tests testdbapi.py,1.1,1.2

From: Carsten H. <ch...@us...> - 2005-10-20 14:52:35

Update of /cvsroot/informixdb/informixdb/tests
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24119

Modified Files:
	testdbapi.py 
Log Message:
callproc test failed on IDS 9 because con.close() rolled back the
procedure creation. Fixed.


Index: testdbapi.py
===================================================================
RCS file: /cvsroot/informixdb/informixdb/tests/testdbapi.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** testdbapi.py	16 Oct 2005 11:54:48 -0000	1.1
--- testdbapi.py	20 Oct 2005 14:52:05 -0000	1.2
***************
*** 54,57 ****
--- 54,58 ----
                  pass
              c.execute(self.storedproc)
+             con.commit()
          finally:
              con.close()

[Informixdb-cvs] informixdb/ext _informixdb.ec,1.17,1.18

From: Carsten H. <ch...@us...> - 2005-10-20 04:39:12

Update of /cvsroot/informixdb/informixdb/ext
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21587

Modified Files:
	_informixdb.ec 
Log Message:
Detailed documentation will go into an external manual. Turn doc strings
into less verbose, markup-free command-line help.


Index: _informixdb.ec
===================================================================
RCS file: /cvsroot/informixdb/informixdb/ext/_informixdb.ec,v
retrieving revision 1.17
retrieving revision 1.18
diff -C2 -d -r1.17 -r1.18
*** _informixdb.ec	18 Oct 2005 20:43:32 -0000	1.17
--- _informixdb.ec	20 Oct 2005 04:39:01 -0000	1.18
***************
*** 101,140 ****
  
  PyDoc_STRVAR(ExcWarning_doc,
! "Exception raised for SQL warnings.\n\n\
! The value of ``SQLSTATE`` is used to determine if a particular\n\
! errorcode should be treated as `Warning`.\n\n\
! :Note: The default `Connection.errorhandler`/`Cursor.errorhandler`\n\
!        never actually raises this exception, it is only present\n\
!        in the `Connection.messages`/`Cursor.messages` list.\n\n\
! :Note: Some warnings (e.g. data truncation) are only generated for\n\
!        an ANSI compatible database.");
  
  PyDoc_STRVAR(ExcError_doc,
! "Exception that serves as base for all Informix DB exceptions\n\
! except for `Warning`.");
  
  PyDoc_STRVAR(ExcInterfaceError_doc,
! "Exception raised for errors in the database interface.\n\n\
  This exception is currently raised when trying to use a closed\n\
! `Connection`, `Cursor`, when too few or too many parameters\n\
! are passed to `Cursor.execute` or when an internal datetime\n\
  conversion error occurs.");
  
  PyDoc_STRVAR(ExcDatabaseError_doc,
! "Exception raised for errors related to the database.\n\n\
! This exception serves as base class for more specific database\n\
! errors and as catchall for database errors which don't fit into\n\
! any other category.\n\n\
! Informix DB uses ``SQLSTATE`` classes to map database errors to\n\
! specific exception classes. In some cases however the database\n\
! does not provide useful values for the error class and Informix DB\n\
! falls back to `DatabaseError`.");
  
  PyDoc_STRVAR(ExcInternalError_doc,
! "Exception raised for errors internal to the database.\n\n\
  This exception is raised for invalid cursor or transaction states.");
  
  PyDoc_STRVAR(ExcOperationalError_doc,
! "Exception raised for operational database errors that aren't\n\
  necessarily under the programmer's control.\n\n\
  Raised for connection problems, situations where the database runs\n\
--- 101,140 ----
  
  PyDoc_STRVAR(ExcWarning_doc,
! "Exception class for SQL warnings.\n\n\
! The value of SQLSTATE is used to determine if a particular\n\
! errorcode should be treated as Warning.\n\n\
! Note: The default errorhandler never raises this exception. If the\n\
!       database reports a Warning, it will be placed into the\n\
!       Cursor's and Connection's messages list.");
  
  PyDoc_STRVAR(ExcError_doc,
! "Base class for all informixdb exceptions that are not Warnings.");
  
  PyDoc_STRVAR(ExcInterfaceError_doc,
! "Exception class for errors in the database interface.\n\n\
  This exception is currently raised when trying to use a closed\n\
! Connection or Cursor, when too few or too many parameters\n\
! are passed to Cursor.execute, or when an internal datetime\n\
  conversion error occurs.");
  
  PyDoc_STRVAR(ExcDatabaseError_doc,
! "Base exception class for errors related to the database.\n\n\
! This exception class is the base class for more specific database\n\
! errors. A generic DatabaseError will be raised when the SQLSTATE\n\
! does not provide enough information to raise a more specific\n\
! exception.\n\n\
! All DatabaseError exceptions, and their derived classes, provide the\n\
! following attributes:\n\
! \n\
! - sqlcode: The Informix SQLCODE associated with the error\n\
! - diagnostics: A list of dictionaries with keys 'sqlstate' and\n\
!                'message' that describe the error in detail.");
  
  PyDoc_STRVAR(ExcInternalError_doc,
! "Exception class for errors internal to the database.\n\n\
  This exception is raised for invalid cursor or transaction states.");
  
  PyDoc_STRVAR(ExcOperationalError_doc,
! "Exception class for operational database errors that aren't\n\
  necessarily under the programmer's control.\n\n\
  Raised for connection problems, situations where the database runs\n\
***************
*** 143,160 ****
  
  PyDoc_STRVAR(ExcProgrammingError_doc,
! "Exception raised for errors caused by the program.\n\n\
  Raised e.g. when an invalid table is referenced, a syntax error\n\
  occurs or an SQL statement is invalid.");
  
  PyDoc_STRVAR(ExcIntegrityError_doc,
! "Exception raised when an integrity constraint would be violated.");
  
  PyDoc_STRVAR(ExcDataError_doc,
! "Exception raised for errors that occur due to the processed data.\n\n\
  Raised e.g. for a division by zero error or when a numeric value\n\
  is out of range.");
  
  PyDoc_STRVAR(ExcNotSupportedError_doc,
! "Exception raised for trying to use a missing or unsupported feature.\n\n\
  Raised when trying to rollback a transaction on a database which\n\
  doesn't support transactions or when the database doesn't support a\n\
--- 143,160 ----
  
  PyDoc_STRVAR(ExcProgrammingError_doc,
! "Exception class for errors caused by the program.\n\n\
  Raised e.g. when an invalid table is referenced, a syntax error\n\
  occurs or an SQL statement is invalid.");
  
  PyDoc_STRVAR(ExcIntegrityError_doc,
! "Exception class for integrity constraint violations.");
  
  PyDoc_STRVAR(ExcDataError_doc,
! "Exception class for errors that occur due to the processed data.\n\n\
  Raised e.g. for a division by zero error or when a numeric value\n\
  is out of range.");
  
  PyDoc_STRVAR(ExcNotSupportedError_doc,
! "Exception class for trying to use a missing or unsupported feature.\n\n\
  Raised when trying to rollback a transaction on a database which\n\
  doesn't support transactions or when the database doesn't support a\n\
***************
*** 248,298 ****
  Close the cursor now.\n\n\
  The cursor will be unusable from this point forward. Any\n\
! operations on it will raise an `InterfaceError`");
  
  PyDoc_STRVAR(Cursor_execute_doc,
! "execute(operation [,seq_of_parameters])\n\n\
  Execute an arbitrary SQL statement.\n\n\
! `operation` is a string containing the SQL statements with optional\n\
! placeholders, where either ``qmark``-style\n\
! (``SELECT * FROM names WHERE name = ?``) or ``numeric``-style\n\
! (``SELECT * FROM names WHERE name = :1``) can be used.\n\
  \n\
! `seq_of_parameters` is a sequence of values to be bound to the\n\
  placeholders in the SQL statement. The number of values in the\n\
  sequence must match the number of parameters required by the SQL\n\
! statement exactly. The types which are used for binding are\n\
  automatically derived from the Python types. For strings and\n\
! integers this is straightforward. To be able to bind date, time\n\
! and binary (``BYTE``/``TEXT``) values the module provides the\n\
! constructors `Date`, `Time`, `Timestamp`, `Binary` and some more\n\
! to construct date and time values from UNIX ticks.\n\
! \n\
! Be careful when trying to pass in a single string for\n\
! `seq_of_parameters`, because it would be interpreted as a\n\
! sequence. To get what is most likely the desired effect you have\n\
! to wrap it in a tuple, e.g.:\n\
! \n\
! >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'joe')\n\
! Traceback (most recent call last):\n\
!   File \"<stdin>\", line 1, in ?\n\
! _informixdb.InterfaceError: too many actual parameters\n\
! >>> cursor.execute('SELECT * FROM names WHERE first=:1', ('joe',))\n\
! \n"
! ":Note: Informix DB implements the operation-caching optimization.\n\
!         This means that passing the same operation object to the\n\
!         same `Cursor` object's `execute` method multiple times in a\n\
!         row will prepare the statement only once. This may result\n\
!         in a significant improvement in execution speed when the\n\
!         same statement is executed many times with different\n\
!         parameters.\n\
! \n\
! :Returns: `execute` will return the number of affected rows for\n\
!           statements which modify data, ``-1`` where the number of\n\
!           affected rows cannot be determined or `None` for statements\n\
!           which return a result set. As the behaviour of the return\n\
!           value is not specified in the DB-API 2.0 specification you\n\
!           are best advised using `rowcount` to determine the number\n\
!           of affected rows, as this will provide the same information\n\
!           in a standards compliant way.");
  
  PyDoc_STRVAR(Cursor_executemany_doc,
--- 248,269 ----
  Close the cursor now.\n\n\
  The cursor will be unusable from this point forward. Any\n\
! operations on it will raise an InterfaceError.");
  
  PyDoc_STRVAR(Cursor_execute_doc,
! "execute(operation [,parameters])\n\n\
  Execute an arbitrary SQL statement.\n\n\
! 'operation' is a string containing the SQL statements with optional\n\
! placeholders, where either qmark-style\n\
! (SELECT * FROM names WHERE name = ?) or numeric-style\n\
! (SELECT * FROM names WHERE name = :1) may be used.\n\
  \n\
! 'parameters' is a sequence of values to be bound to the\n\
  placeholders in the SQL statement. The number of values in the\n\
  sequence must match the number of parameters required by the SQL\n\
! statement exactly. The data types which are used for binding are\n\
  automatically derived from the Python types. For strings and\n\
! integers this is straightforward. For binding date, time, datetime,\n\
! and binary (BYTE/TEXT) values, the module provides constructors\n\
! for constructing the corresponding Python types.");
  
  PyDoc_STRVAR(Cursor_executemany_doc,
***************
*** 301,325 ****
  parameters.\n\
  \n\
! The `operation` parameter is the same as for `execute`,\n\
! `seq_of_parameters` is a sequence of parameter tuples (or more\n\
! generally sequences) suitable for passing to `execute`. This will\n\
! invoke `execute` for all parameter sequences in `seq_of_parameters`,\n\
! but will still be fast since the operation is prepared only once.\n\
  \n\
! For batch inserts a special optimization applies, which will make\n\
! use of insert cursors. This can result in a huge speed increase\n\
! compared to calling `execute` multiple times, especially when used\n\
! over a network.\n\
  \n\
! :Seealso: `execute`");
  
  PyDoc_STRVAR(Cursor_fetchone_doc,
! "fetchone() -> sequence\n\n\
  Fetch the next row of a query result set.\n\n\
! The next row is returned either as sequence or as mapping,\n\
! depending on how the `Cursor` was created (see\n\
! `Connection.cursor`). When no more rows are are available\n\
! `None` is returned.\n\n\
! Calling `fetchone` when no statement was executed or after\n\
  a statement that does not produce a result set was executed\n\
  will raise an Error.");
--- 272,294 ----
  parameters.\n\
  \n\
! The 'operation' parameter is the same as for execute.\n\
! 'seq_of_parameters' is a sequence of parameter sequences suitable\n\
! for passing to execute(). The operation will be prepared once and\n\
! then executes for all parameter sequences in 'seq_of_parameters'.\n\
  \n\
! For insert statements, executemany() will use an insert cursor\n\
! if the database supports transactions. This will result in a\n\
! dramatic speed increase for batch inserts.\n\
  \n\
! See also: Cursor.execute()");
  
  PyDoc_STRVAR(Cursor_fetchone_doc,
! "fetchone() -> tuple or dictionary\n\n\
  Fetch the next row of a query result set.\n\n\
! The next row is returned either as a tuple or as a dictionary,\n\
! depending on how the Cursor was created (see\n\
! Connection.cursor()). When no more rows are are available,\n\
! None is returned.\n\n\
! Calling fetchone() when no statement was executed or after\n\
  a statement that does not produce a result set was executed\n\
  will raise an Error.");
***************
*** 328,373 ****
  "fetchmany([size=Cursor.arraysize]) -> list\n\n\
  Fetch a specified number of rows of a query result set.\n\n\
! Return up to `size` rows in a list, or fewer if there are no more\n\
! rows available. An empty list is returned if no row is available.\n\
  \n\
! The types of the rows and the behaviour in error cases is the same\n\
! as for `fetchone`.");
  
  PyDoc_STRVAR(Cursor_fetchall_doc,
  "fetchall() -> list\n\n\
! Fetch all (remaining) rows of a query result set.\n\n\
  Return as many rows as there are available in the result set or an\n\
  empty list if there are no more rows available.\n\
  \n\
! The types of the rows and the behaviour in error cases is the same\n\
! as for `fetchone`.");
  
  PyDoc_STRVAR(Cursor_setinputsizes_doc,
  "setinputsizes(sizes)\n\n\
! Provide hints to optimize memory allocation for input parameters.\n\n\
! Informix DB does not implement this optimization.");
  
  PyDoc_STRVAR(Cursor_setoutputsize_doc,
  "setoutputsize(size[,column])\n\n\
! Provide hints to optimize memory allocation for large output values.\n\n\
! Informix DB does not implement this optimization.");
  
  PyDoc_STRVAR(Cursor_callproc_doc,
  "callproc(procname[,parameters]) -> sequence\n\n\
  Execute a stored procedure.\n\n\
! Call the stored procedure `procname` with parameters as given in\n\
! the sequence `parameters`. This is preferable to `execute` with an\n\
! ``EXECUTE PROCEDURE ...`` statement in most cases, because it\n\
! should also work with other DB-API 2.0 implementations.\n\
! \n\
! If the stored procedure generates a result set it can be accessed\n\
! through the standard fetch methods.\n\
  \n\
! :Returns: The unmodified input sequence, because Informix doesn't\n\
!           support ``out`` or ``in/out`` arguments on stored\n\
!           procedures (the specification says that a copy of the\n\
!           input sequence should be returned, where ``out`` and\n\
!           ``in/out`` arguments are replaced by their new values).\n\
! ");
  
  static PyMethodDef Cursor_methods[] = {
--- 297,333 ----
  "fetchmany([size=Cursor.arraysize]) -> list\n\n\
  Fetch a specified number of rows of a query result set.\n\n\
! Return up to 'size' rows in a list, or fewer if there are no more\n\
! rows available. An empty list is returned if no more rows are\n\
! available.\n\
  \n\
! See also: fetchone()");
  
  PyDoc_STRVAR(Cursor_fetchall_doc,
  "fetchall() -> list\n\n\
! Fetch all remaining rows of a query result set.\n\n\
  Return as many rows as there are available in the result set or an\n\
  empty list if there are no more rows available.\n\
  \n\
! See also: fetchone()");
  
  PyDoc_STRVAR(Cursor_setinputsizes_doc,
  "setinputsizes(sizes)\n\n\
! informixdb does not implement this optimization.");
  
  PyDoc_STRVAR(Cursor_setoutputsize_doc,
  "setoutputsize(size[,column])\n\n\
! informixdb does not implement this optimization.");
  
  PyDoc_STRVAR(Cursor_callproc_doc,
  "callproc(procname[,parameters]) -> sequence\n\n\
  Execute a stored procedure.\n\n\
! Call the stored procedure 'procname' with parameters as given in\n\
! the sequence 'parameters'. This is preferable to execute() with an\n\
! EXECUTE PROCEDURE statement since it is portable to other DB-API 2.0\n\
! implementations.\n\
  \n\
! Returns: The unmodified input sequence, because Informix doesn't\n\
!          support \"out\" or \"in/out\" arguments for stored\n\
!          procedures.");
  
  static PyMethodDef Cursor_methods[] = {
***************
*** 395,403 ****
  PyDoc_STRVAR(Cursor_messages_doc,
  "List of SQL warning and error messages.\n\n\
! :Seealso: `Connection.messages`");
  
  PyDoc_STRVAR(Cursor_errorhandler_doc,
  "Python callable which is invoked for SQL errors.\n\n\
! :Seealso: `Connection.errorhandler`"
  );
  
--- 355,363 ----
  PyDoc_STRVAR(Cursor_messages_doc,
  "List of SQL warning and error messages.\n\n\
! See also: Connection.messages");
  
  PyDoc_STRVAR(Cursor_errorhandler_doc,
  "Python callable which is invoked for SQL errors.\n\n\
! See also: Connection.errorhandler"
  );
  
***************
*** 426,454 ****
  PyDoc_STRVAR(Cursor_doc,
  "Executes SQL statements and fetches their results.\n\n\
! `Cursor` objects are the central objects in interacting with the\n\
  database since they provide the methods necessary to execute SQL\n\
  statements and fetch results from the database.\n\
  \n\
! To create a `Cursor` object call `Connection.cursor`.\n\
! \n\
! You can then use the `execute`, `executemany` and `callproc` methods\n\
! to issue SQL statements and get their results with `fetchone`,\n\
! `fetchmany`, `fetchall` or by iterating over the `Cursor` object.\n\
! \n\
! :Note: Iterating over a `Cursor` object is an extension to the\n\
!        DB-API 2.0 specification.\n\
! \n\
! :Note: As an extension to the DB-API 2.0 specification Informix DB\n\
!        provides named cursors which allow you to use the\n\
!        ``... WHERE CURRENT OF ...`` clause in your SQL statements.\n\
!        For information on how to use them see the `Connection.cursor`\n\
!        documentation.\n\
  \n\
! :Note: `Cursor` objects do not directly map to underlying database\n\
!        cursors. Actual database cursors are created in `execute`,\n\
!        `executemany` or `callproc` when needed (i.e. for ``SELECT``\n\
!        and ``EXECUTE PROCEDURE`` statements) and closed upon the\n\
!        next invocation of `execute`, `executemany` or `callproc` or\n\
!        when the `Cursor` object is deallocated.");
  
  static PyTypeObject Cursor_type = {
--- 386,398 ----
  PyDoc_STRVAR(Cursor_doc,
  "Executes SQL statements and fetches their results.\n\n\
! Cursor objects are the central objects in interacting with the\n\
  database since they provide the methods necessary to execute SQL\n\
  statements and fetch results from the database.\n\
  \n\
! To create a Cursor object, call Connection.cursor().\n\
  \n\
! You can then use the execute(), executemany(), and callproc() methods\n\
! to issue SQL statements and get their results with fetchone(),\n\
! fetchmany(), fetchall(), or by iterating over the Cursor object.");
  
  static PyTypeObject Cursor_type = {
***************
*** 523,572 ****
  PyDoc_STRVAR(Connection_cursor_doc,
  "cursor([name=None,rowformat=_informixdb.ROW_AS_TUPLE]) -> Cursor\n\n\
! Return a new `Cursor` object using the connection.\n\
! \n\
! `name` is an extension to the DB-API 2.0 specification and allows\n\
! you to optionally name your cursor. This is only useful when the\n\
! cursor is going to be used in ``'WHERE CURRENT OF <name>'`` clauses\n\
! in SQL statements. Note however, that you will have to use a second\n\
! `Cursor` object to perform the operation, since trying to execute\n\
! the ``'... WHERE CURRENT OF ...'`` statement with the named `Cursor`\n\
! object itself will close it.\n\
  \n\
! `rowformat` is an extension to the DB-API 2.0 specification that\n\
! can be used to specify that dictionaries with the column names as\n\
! keys should be used as return values of `Cursor.fetchone`,\n\
! `Cursor.fetchmany` and `Cursor.fetchall` instead of tuples. To\n\
! select this behaviour use `_informixdb.ROW_AS_DICT` for `rowformat`,\n\
! e.g.:\n\
  \n\
! >>> cursor = conn.cursor(rowformat=_informixdb.ROW_AS_DICT)\n\
! >>> cursor.execute('SELECT * FROM names')\n\
! >>> cursor.fetchall()\n\
! [{'age': 34, 'last': 'duck', 'first': 'donald'},\n\
!  {'age': 23, 'last': 'mouse', 'first': 'mickey'}]");
  
  PyDoc_STRVAR(Connection_commit_doc,
  "commit()\n\n\
! Commit the current database transaction and start a new one.\n\n\
! `commit` does nothing for databases which have transactions\n\
  disabled.");
  
  PyDoc_STRVAR(Connection_rollback_doc,
  "rollback()\n\n\
! Rollback the current database transaction and start a new one.\n\n\
! `rollback` raises a NotSupportedError for databases which have\n\
  transactions disabled.");
  
  PyDoc_STRVAR(Connection_close_doc,
  "close()\n\n\
! Close the connection and all associated `Cursor` objects.\n\n\
! This is automatically done when the `Connection` object and all\n\
  its associated cursors are destroyed.\n\n\
  After the connection is closed it becomes unusable and all\n\
! operations on it or its associated `Cursor` objects will raise\n\
  an InterfaceError.\n\n\
! For databases which have transactions enabled an implicit rollback\n\
! is performed before the closing the connection, so be sure to\n\
! commit any outstanding operations before closing a `Connection`.");
  
  static PyMethodDef Connection_methods[] = {
--- 467,503 ----
  PyDoc_STRVAR(Connection_cursor_doc,
  "cursor([name=None,rowformat=_informixdb.ROW_AS_TUPLE]) -> Cursor\n\n\
! Return a new Cursor object using the connection.\n\
  \n\
! 'name' allows you to optionally name your cursor. This is useful\n\
! for creating an update or delete cursor that can be used by a second\n\
! cursor in an UPDATE (or DELETE) WHERE CURRENT OF ... statement.\n\
  \n\
! 'rowformat' allows you to optionally specify whether the cursor\n\
! should return fetched result rows as tuples or as dictionaries.");
  
  PyDoc_STRVAR(Connection_commit_doc,
  "commit()\n\n\
! Commit the current database transaction and begin a new transaction.\n\n\
! commit() does nothing for databases which have transactions\n\
  disabled.");
  
  PyDoc_STRVAR(Connection_rollback_doc,
  "rollback()\n\n\
! Rollback the current database transaction and begin a new\n\
! transaction.\n\n\
! rollback() raises a NotSupportedError for databases which have\n\
  transactions disabled.");
  
  PyDoc_STRVAR(Connection_close_doc,
  "close()\n\n\
! Close the connection and all associated Cursor objects.\n\n\
! This is done automatically when the Connection object and all\n\
  its associated cursors are destroyed.\n\n\
  After the connection is closed it becomes unusable and all\n\
! operations on it or its associated Cursor objects will raise\n\
  an InterfaceError.\n\n\
! For databases that have transactions enabled an implicit rollback\n\
! is performed when the connection is closed, so be sure to\n\
! commit any outstanding operations before closing a Connection.");
  
  static PyMethodDef Connection_methods[] = {
***************
*** 583,606 ****
  
  PyDoc_STRVAR(Connection_messages_doc,
! "A list with one ``(exception_class, exception_values)`` tuple for\n\
  each error/warning.\n\n\
! The default `errorhandler` appends any warnings or errors\n\
  concerning the connection to this list. The list is automatically\n\
! cleared by all connection methods and can be manually cleared by\n\
! the user with ``del connection.messages[:]``.\n\n\
! The purpose of these list is to eliminate the need to raise\n\
! Warning exceptions.\n\n\
! :Note: This is an extension to the DB-API 2.0 specification.");
  
  PyDoc_STRVAR(Connection_errorhandler_doc,
  "An optional callable which can be used to customize error reporting.\n\n\
! `errorhandler` can be set to a callable of the form\n\
! ``errorhandler(connection, cursor, errorclass, errorvalue)``\n\
! and will be called for any errors or warnings concerning the\n\
  connection.\n\n\
  The default (if errorhandler is None) is to append the error/warning\n\
! to the `messages` list and raise an exception unless the\n\
! errorclass is `Warning`.\n\n\
! :Note: This is an extension to the DB-API 2.0 specification.");
  
  static PyMemberDef Connection_members[] = {
--- 514,533 ----
  
  PyDoc_STRVAR(Connection_messages_doc,
! "A list with one (exception_class, exception_values) tuple for\n\
  each error/warning.\n\n\
! The default errorhandler appends any warnings or errors\n\
  concerning the connection to this list. The list is automatically\n\
! cleared by all connection methods and can be cleared manually with\n\
! the command \"del connection.messages[:]\".");
  
  PyDoc_STRVAR(Connection_errorhandler_doc,
  "An optional callable which can be used to customize error reporting.\n\n\
! errorhandler can be set to a callable of the form\n\
! errorhandler(connection, cursor, errorclass, errorvalue)\n\
! that will be called for any errors or warnings concerning the\n\
  connection.\n\n\
  The default (if errorhandler is None) is to append the error/warning\n\
! to the messages list and raise an exception if the errorclass is not\n\
! a Warning.");
  
  static PyMemberDef Connection_members[] = {
***************
*** 645,655 ****
  "Connection to an Informix database.\n\n\
  Provides access to transactions and allows the creation of Cursor\n\
! objects via the `cursor` method.\n\n\
! As an extension to the DB-API 2.0 specification Informix DB provides\n\
! the exception classes as attributes of `Connection` objects in addition\n\
  to the module level attributes to simplify error handling in\n\
  multi-connection environments.\n\n\
! :Note: Do not instantiate objects of this class directly. Use the\n\
!        `_informixdb.connect` method instead.");
  
  static PyTypeObject Connection_type = {
--- 572,582 ----
  "Connection to an Informix database.\n\n\
  Provides access to transactions and allows the creation of Cursor\n\
! objects via the cursor() method.\n\n\
! As an extension to the DB-API 2.0 specification, informixdb provides\n\
! the exception classes as attributes of Connection objects in addition\n\
  to the module level attributes to simplify error handling in\n\
  multi-connection environments.\n\n\
! Do not instantiate Connection objects directly. Use the\n\
! informixdb.connect() method instead.");
  
  static PyTypeObject Connection_type = {
***************
*** 2479,2486 ****
  "connect(dsn[,user,password]) -> Connection\n\n\
  Establish a connection to a database.\n\n\
! `dsn` identifies a database environment as accepted by the CONNECT\n\
! statement. It can be the name of a database (``'stores7'``) the name\n\
! of a database server (``'@valley'``) or a combination thereof\n\
! (``'stores7@valley'``).");
  
  PyDoc_STRVAR(db_Date_doc,
--- 2406,2413 ----
  "connect(dsn[,user,password]) -> Connection\n\n\
  Establish a connection to a database.\n\n\
! 'dsn' identifies a database environment as accepted by the CONNECT\n\
! statement. It can be the name of a database ('stores7'), the name\n\
! of a database server ('@valley'), or a combination thereof\n\
! ('stores7@valley').");
  
  PyDoc_STRVAR(db_Date_doc,
***************
*** 2491,2506 ****
  "Time(hour,minute,second[,microsecond=0]) -> datetime.datetime\n\n\
  Construct an object holding a time value.\n\n\
! :Note: `microsecond` is an extension to the DB-API specification. It\n\
!        represents the fractional part of an Informix DATETIME column,\n\
!        and is therefore limited to a maximum of 10 microseconds of\n\
!        accuracy.");
  
  PyDoc_STRVAR(db_Timestamp_doc,
! "Timestamp(year,month,day,hour=0,minute=0,second=0,microsecond=0) -> datetime.datetime\n\n\
  Construct an object holding a time stamp (datetime) value.\n\n\
! :Note: `microsecond` is an extension to the DB-API specification. It\n\
!        represents the fractional part of an Informix DATETIME column,\n\
!        and is therefore limited to a maximum of 10 microseconds of\n\
!        accuracy.");
  
  PyDoc_STRVAR(db_TimestampFromTicks_doc,
--- 2418,2434 ----
  "Time(hour,minute,second[,microsecond=0]) -> datetime.datetime\n\n\
  Construct an object holding a time value.\n\n\
! Note: 'microsecond' is an extension to the DB-API specification. It\n\
!       represents the fractional part of an Informix DATETIME column,\n\
!       and is therefore limited to a maximum of 10 microseconds of\n\
!       accuracy.");
  
  PyDoc_STRVAR(db_Timestamp_doc,
! "Timestamp(year,month,day,hour=0,minute=0,second=0,microsecond=0)\n\
!   -> datetime.datetime\n\n\
  Construct an object holding a time stamp (datetime) value.\n\n\
! Note: 'microsecond' is an extension to the DB-API specification. It\n\
!       represents the fractional part of an Informix DATETIME column,\n\
!       and is therefore limited to a maximum of 10 microseconds of\n\
!       accuracy.");
  
  PyDoc_STRVAR(db_TimestampFromTicks_doc,
***************
*** 2508,2538 ****
  Construct an object holding a time stamp (datetime) from the given\n\
  ticks value.\n\n\
! `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\n\
! :Note: Using ticks might cause problems, because they cover only a\n\
!        limited time range. See the standard Python `time` and `datetime`\n\
!        modules' documentation for details.");
  
  PyDoc_STRVAR(db_DateFromTicks_doc,
  "DateFromTicks(ticks) -> datetime.date\n\n\
  Construct an object holding a date value from the given ticks value.\n\n\
! `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\n\
! :Note: Using ticks might cause problems, because they cover only a\n\
!        limited time range. See the standard Python `time` and `datetime`\n\
!        modules' documentation for details.");
  
  PyDoc_STRVAR(db_TimeFromTicks_doc,
  "TimeFromTicks(ticks) -> datetime.datetime\n\n\
  Construct an object holding a time value from the given ticks value.\n\n\
! `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\n\
! :Note: Using ticks might cause problems, because they cover only a\n\
!        limited time range. See the standard Python `time` and `datetime`\n\
!        modules' documentation for details.");
  
  PyDoc_STRVAR(db_Binary_doc,
  "Binary(string) -> buffer\n\n\
! Construct an object capable of holding a binary (long) value.");
  
  static PyMethodDef globalMethods[] = {
--- 2436,2454 ----
  Construct an object holding a time stamp (datetime) from the given\n\
  ticks value.\n\n\
! 'ticks' are the number of seconds since the start of the current epoch.");
  
  PyDoc_STRVAR(db_DateFromTicks_doc,
  "DateFromTicks(ticks) -> datetime.date\n\n\
  Construct an object holding a date value from the given ticks value.\n\n\
! 'ticks' are the number of seconds since the start of the current epoch.");
  
  PyDoc_STRVAR(db_TimeFromTicks_doc,
  "TimeFromTicks(ticks) -> datetime.datetime\n\n\
  Construct an object holding a time value from the given ticks value.\n\n\
! 'ticks' are the number of seconds since the start of the current epoch.");
  
  PyDoc_STRVAR(db_Binary_doc,
  "Binary(string) -> buffer\n\n\
! Construct an object capable of holding a BYTE or TEXT value.");
  
  static PyMethodDef globalMethods[] = {
***************
*** 2557,2577 ****
  
  PyDoc_STRVAR(_informixdb_doc,
! "`DB-API 2.0`_ compliant interface for Informix databases.\n\
! \n\
! To get you started:\n\
! \n\
! >>> import informixdb\n\
! >>> conn = informixdb.connect('mydatabase')\n\
! >>> cursor = conn.cursor()\n\
! >>> cursor.execute('SELECT * FROM names')\n\
! >>> cursor.fetchall()\n\
! [('donald', 'duck', 34), ('mickey', 'mouse', 23)]\n\
! \n\
! .. _DB-API 2.0: http://www.python.org/peps/pep-0249.html\n\
! \n\
! :Note: Informix DB uses the `datetime` module to represent date, time and\n\
!        timestamp values. It is part of the standard library since\n\
!        Python 2.3 and is automatically installed by Informix DB for older\n\
!        Python versions.");
  
  void init_informixdb(void)
--- 2473,2477 ----
  
  PyDoc_STRVAR(_informixdb_doc,
! "DB-API 2.0 compliant interface for Informix databases.\n");
  
  void init_informixdb(void)

[Informixdb-cvs] informixdb informixdb.py,1.8,1.9

From: Carsten H. <ch...@us...> - 2005-10-20 02:52:18

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4980

Modified Files:
	informixdb.py 
Log Message:
promote the Connection and Cursor class documentation into the informixdb
namespace and add rudimentary top level documentation.


Index: informixdb.py
===================================================================
RCS file: /cvsroot/informixdb/informixdb/informixdb.py,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** informixdb.py	18 Oct 2005 20:43:32 -0000	1.8
--- informixdb.py	20 Oct 2005 02:52:09 -0000	1.9
***************
*** 31,37 ****
  #
  
! """ DB-API 2.0 compliant interface for Informix databases.
  
! For full documentation please try `_informixdb`"""
  
  from _informixdb import *
--- 31,56 ----
  #
  
! """\
!  DB-API 2.0 compliant interface for IBM Informix databases.
  
! Here's a small example to get you started:
! 
! >>> import informixdb
! >>> conn = informixdb.connect('mydatabase')
! >>> cursor = conn.cursor()
! >>> cursor.execute('SELECT * FROM names')
! >>> cursor.fetchall()
! [('donald', 'duck', 34), ('mickey', 'mouse', 23)]
! 
! For more information on DB-API 2.0, see
! http://www.python.org/peps/pep-0249.html
! """
  
  from _informixdb import *
+ 
+ # promote the class definitions of _informixdb.Cursor and
+ # _informixdb.Connection into this namespace so that help(informixdb)
+ # sees their doc strings.
+ from _informixdb import Cursor as _Cursor, Connection as _Connection
+ class Cursor(_Cursor): pass
+ class Connection(_Connection): pass

[Informixdb-cvs] informixdb MANIFEST,1.1,1.2

From: Carsten H. <ch...@us...> - 2005-10-20 02:44:05

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3756

Modified Files:
	MANIFEST 
Log Message:
include test suite for distribution


Index: MANIFEST
===================================================================
RCS file: /cvsroot/informixdb/informixdb/MANIFEST,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** MANIFEST	19 Oct 2005 04:19:09 -0000	1.1
--- MANIFEST	20 Oct 2005 02:43:54 -0000	1.2
***************
*** 7,8 ****
--- 7,10 ----
  ext/_informixdb.ec
  ext/datetime-compat.h
+ tests/dbapi20.py
+ tests/testdbapi.py

[Informixdb-cvs] informixdb README,1.5,1.6

From: Carsten H. <ch...@us...> - 2005-10-19 13:31:32

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11871

Modified Files:
	README 
Log Message:
1.5 was missing in the release history. Better late than never...


Index: README
===================================================================
RCS file: /cvsroot/informixdb/informixdb/README,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** README	19 Oct 2005 04:47:15 -0000	1.5
--- README	19 Oct 2005 13:31:13 -0000	1.6
***************
*** 239,242 ****
--- 239,243 ----
  1.3      1999-11-30  Stephen J. Turner
  1.4      2005-04-11  Carsten Haese
+ 1.5      2005-09-18  Carsten Haese
  2.0      TBD         Carsten Haese

[Informixdb-cvs] informixdb README,1.4,1.5

From: Carsten H. <ch...@us...> - 2005-10-19 04:47:23

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1922

Modified Files:
	README 
Log Message:
Corrections and clarifications.


Index: README
===================================================================
RCS file: /cvsroot/informixdb/informixdb/README,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** README	17 Oct 2005 00:40:40 -0000	1.4
--- README	19 Oct 2005 04:47:15 -0000	1.5
***************
*** 21,26 ****
  
  This distribution uses Python distutils to build and install the informixdb
! module.  It should work with Python 1.5.2 or later as long as distutils is
! present.
  
  
--- 21,25 ----
  
  This distribution uses Python distutils to build and install the informixdb
! module.  It requires Python 2.2 or later.
  
  
***************
*** 34,38 ****
  --------------------
  
! First, extract the source distribution on a machine with Python 1.5.2 or
  later and INFORMIX-ESQL/C, and `cd' to the top-level directory.
  
--- 33,37 ----
  --------------------
  
! First, extract the source distribution on a machine with Python 2.2 or
  later and INFORMIX-ESQL/C, and `cd' to the top-level directory.
  
***************
*** 63,70 ****
  ====================
  
! I'm afraid you're on your own.  distutils should do the Right Thing, but
! I haven't had the chance to try this yet. If you have had any success (or
! failure, for that matter) with building and installing InformixDB on Windows,
! I'd like to hear about it.
  
  
--- 62,74 ----
  ====================
  
! A Windows installer for Python 2.4 is available for download at
! http://sourceforge.net/projects/informixdb. Download it and run it to
! install the InformixDB module. Note that you'll need the Informix Client SDK
! to use the InformixDB module.
! 
! If you're using a different version of Python, you'll have to compile
! InformixDB from the sources, following the same steps as for a Unix
! installation. Distutils should do the right thing as long as you have the same
! compiler that produced the Python interpreter you're using.
  
  
***************
*** 202,206 ****
  - Implement useful optional DB-API extensions if there are any that Daniel
    hasn't already implemented. ;)
- - Work out Windows installation procedure
  - Low priority unless people ask for it: support SLOBs and UDTs.
  
--- 206,209 ----
***************
*** 209,213 ****
  
  Got questions and/or problems with informixdb?  Contact me at:
!   Carsten Haese <car...@sb...>
  
  I'd recommend that you also consider CC'ing the Python DB-SIG at:
--- 212,216 ----
  
  Got questions and/or problems with informixdb?  Contact me at:
!   Carsten Haese <ch...@us...>
  
  I'd recommend that you also consider CC'ing the Python DB-SIG at:
***************
*** 239,242 ****
  
  --
! Carsten Haese <car...@sb...>
  http://sourceforge.net/projects/informixdb
--- 242,245 ----
  
  --
! Carsten Haese <ch...@us...>
  http://sourceforge.net/projects/informixdb

[Informixdb-cvs] informixdb setup.py,1.6,1.7

From: Carsten H. <ch...@us...> - 2005-10-19 04:21:02

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30784

Modified Files:
	setup.py 
Log Message:
Include copyright notice/warranty disclaimer in the description that the
Windows installer presents.
Add detailed package metadata.


Index: setup.py
===================================================================
RCS file: /cvsroot/informixdb/informixdb/setup.py,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** setup.py	18 Oct 2005 05:09:00 -0000	1.6
--- setup.py	19 Oct 2005 04:20:53 -0000	1.7
***************
*** 7,10 ****
--- 7,11 ----
  from distutils.util import get_platform
  from distutils.command.build_ext import build_ext as _build_ext
+ from distutils.command.bdist_wininst import bdist_wininst as _bdist_wininst
  from distutils.dep_util import newer_group
  from distutils.errors import *
***************
*** 128,131 ****
--- 129,142 ----
          _build_ext.build_extension(self, ext)
  
+ class bdist_wininst(_bdist_wininst):
+     """ override bdist_wininst to include the license in the description. """
+     def get_inidata(self):
+         metadata = self.distribution.metadata
+         save_long_desc = metadata.long_description
+         metadata.long_description += "\n\n" + file("COPYRIGHT").read() + "\n"
+         result = _bdist_wininst.get_inidata(self)
+         metadata.long_description = save_long_desc
+         return result
+ 
  def have_c_datetime():
      """ Check whether the datetime C API is available. """
***************
*** 162,169 ****
                      define_macros = extra_macros )
  
  setup (name = 'InformixDB',
         version = '2.0',
         description = 'InformixDB v2.0',
         py_modules = modules,
         ext_modules = [module1],
!        cmdclass = { 'build_ext' : build_ext })
--- 173,210 ----
                      define_macros = extra_macros )
  
+ # patch distutils if it can't cope with the "classifiers" or 
+ # "download_url" keywords
+ if sys.version < '2.2.3':
+     from distutils.dist import DistributionMetadata
+     DistributionMetadata.classifiers = None
+     DistributionMetadata.download_url = None
+ 
  setup (name = 'InformixDB',
         version = '2.0',
         description = 'InformixDB v2.0',
+        long_description = \
+          "InformixDB is a DB-API 2.0 compliant interface for IBM Informix\n"
+          "databases.",
+        maintainer = "Carsten Haese",
+        maintainer_email = "ch...@us...",
+        url = "http://sourceforge.net/projects/informixdb",
+        license = "BSD License",
+        platforms = ["POSIX", "Microsoft Windows 95/98/NT/2000/XP"],
+        classifiers=[
+          "Development Status :: 5 - Production/Stable",
+          "Environment :: Console",
+          "Intended Audience :: Developers",
+          "License :: OSI Approved :: BSD License",
+          "Operating System :: Microsoft :: Windows :: Windows 95/98/2000",
+          "Operating System :: Microsoft :: Windows :: Windows NT/2000",
+          "Operating System :: POSIX",
+          "Programming Language :: C",
+          "Programming Language :: Python",
+          "Topic :: Database :: Front-Ends"
+        ],
         py_modules = modules,
         ext_modules = [module1],
!        cmdclass = {
!          'build_ext' : build_ext,
!          'bdist_wininst': bdist_wininst
!        } )

[Informixdb-cvs] informixdb MANIFEST,NONE,1.1

From: Carsten H. <ch...@us...> - 2005-10-19 04:19:20

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30592

Added Files:
	MANIFEST 
Log Message:
Add manifest so that distutils can automagically roll source distributions.


--- NEW FILE: MANIFEST ---
README
COPYRIGHT
MANIFEST
informixdb.py
datetime.py
setup.py
ext/_informixdb.ec
ext/datetime-compat.h

[Informixdb-cvs] informixdb informixdb.py,1.7,1.8

From: Daniel S. <da...@us...> - 2005-10-18 20:43:46

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23726

Modified Files:
	informixdb.py 
Log Message:
more documentation stuff:
  * note in informixdb.py where to find full documentation
  * minor fixups in a few docstrings
  * made DatabaseError/Warning attributes visible for inspection
  * reflowed docstrings so that help displays them correctly on 80-char
    terminals


Index: informixdb.py
===================================================================
RCS file: /cvsroot/informixdb/informixdb/informixdb.py,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** informixdb.py	16 Oct 2005 11:53:44 -0000	1.7
--- informixdb.py	18 Oct 2005 20:43:32 -0000	1.8
***************
*** 31,33 ****
--- 31,37 ----
  #
  
+ """ DB-API 2.0 compliant interface for Informix databases.
+ 
+ For full documentation please try `_informixdb`"""
+ 
  from _informixdb import *

[Informixdb-cvs] informixdb/ext _informixdb.ec,1.16,1.17

From: Daniel S. <da...@us...> - 2005-10-18 20:43:42

Update of /cvsroot/informixdb/informixdb/ext
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23726/ext

Modified Files:
	_informixdb.ec 
Log Message:
more documentation stuff:
  * note in informixdb.py where to find full documentation
  * minor fixups in a few docstrings
  * made DatabaseError/Warning attributes visible for inspection
  * reflowed docstrings so that help displays them correctly on 80-char
    terminals


Index: _informixdb.ec
===================================================================
RCS file: /cvsroot/informixdb/informixdb/ext/_informixdb.ec,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** _informixdb.ec	18 Oct 2005 03:16:41 -0000	1.16
--- _informixdb.ec	18 Oct 2005 20:43:32 -0000	1.17
***************
*** 102,129 ****
  PyDoc_STRVAR(ExcWarning_doc,
  "Exception raised for SQL warnings.\n\n\
! The value of ``SQLSTATE`` is used to determine if a particular errorcode\n\
! should be treated as `Warning`.\n\n\
! :Note: The default `Connection.errorhandler`/`Cursor.errorhandler` never\n\
!        actually raises this exception, it is only present in the \n\
!        `Connection.messages`/`Cursor.messages` list.\n\n\
! :Note: Some warnings (e.g. data truncation) are only generated for an ANSI\n\
!        compatible database.");
  
  PyDoc_STRVAR(ExcError_doc,
! "Exception that servers as base for all Informix DB exceptions except for `Warning`.");
  
  PyDoc_STRVAR(ExcInterfaceError_doc,
  "Exception raised for errors in the database interface.\n\n\
! This exception is currently raised when trying to use a closed `Connection`\n\
! `Cursor`, when too few or too many parameters are passed to `Cursor.execute`\n\
! or when a (internal) datetime conversion error occurs.");
  
  PyDoc_STRVAR(ExcDatabaseError_doc,
  "Exception raised for errors related to the database.\n\n\
! This exception serves as base class for more specific database errors and\n\
! as catchall for database errors which don't fit into any other category.\n\n\
! Informix DB uses ``SQLSTATE`` classes to map database errors to specific\n\
! exception classes. In some cases however the database doesn't provide\n\
! useful values for the error class and Informix DB falls back to `DatabaseError`.");
  
  PyDoc_STRVAR(ExcInternalError_doc,
--- 102,133 ----
  PyDoc_STRVAR(ExcWarning_doc,
  "Exception raised for SQL warnings.\n\n\
! The value of ``SQLSTATE`` is used to determine if a particular\n\
! errorcode should be treated as `Warning`.\n\n\
! :Note: The default `Connection.errorhandler`/`Cursor.errorhandler`\n\
!        never actually raises this exception, it is only present\n\
!        in the `Connection.messages`/`Cursor.messages` list.\n\n\
! :Note: Some warnings (e.g. data truncation) are only generated for\n\
!        an ANSI compatible database.");
  
  PyDoc_STRVAR(ExcError_doc,
! "Exception that serves as base for all Informix DB exceptions\n\
! except for `Warning`.");
  
  PyDoc_STRVAR(ExcInterfaceError_doc,
  "Exception raised for errors in the database interface.\n\n\
! This exception is currently raised when trying to use a closed\n\
! `Connection`, `Cursor`, when too few or too many parameters\n\
! are passed to `Cursor.execute` or when an internal datetime\n\
! conversion error occurs.");
  
  PyDoc_STRVAR(ExcDatabaseError_doc,
  "Exception raised for errors related to the database.\n\n\
! This exception serves as base class for more specific database\n\
! errors and as catchall for database errors which don't fit into\n\
! any other category.\n\n\
! Informix DB uses ``SQLSTATE`` classes to map database errors to\n\
! specific exception classes. In some cases however the database\n\
! does not provide useful values for the error class and Informix DB\n\
! falls back to `DatabaseError`.");
  
  PyDoc_STRVAR(ExcInternalError_doc,
***************
*** 132,144 ****
  
  PyDoc_STRVAR(ExcOperationalError_doc,
! "Exception raised for operational database errors that aren't necessarily \
! under the programmer's control.\n\n\
! Raised for connection problems, situations where the database runs out\n\
! of memory or when the given credentials don't allow access to the database.");
  
  PyDoc_STRVAR(ExcProgrammingError_doc,
  "Exception raised for errors caused by the program.\n\n\
! Raised e.g. when an invalid table is referenced, a syntax error occurs or\n\
! an SQL statement is invalid.");
  
  PyDoc_STRVAR(ExcIntegrityError_doc,
--- 136,149 ----
  
  PyDoc_STRVAR(ExcOperationalError_doc,
! "Exception raised for operational database errors that aren't\n\
! necessarily under the programmer's control.\n\n\
! Raised for connection problems, situations where the database runs\n\
! out of memory or when the given credentials don't allow access to\n\
! the database.");
  
  PyDoc_STRVAR(ExcProgrammingError_doc,
  "Exception raised for errors caused by the program.\n\n\
! Raised e.g. when an invalid table is referenced, a syntax error\n\
! occurs or an SQL statement is invalid.");
  
  PyDoc_STRVAR(ExcIntegrityError_doc,
***************
*** 147,158 ****
  PyDoc_STRVAR(ExcDataError_doc,
  "Exception raised for errors that occur due to the processed data.\n\n\
! Raised e.g. for a division by zero error or when a numeric value is out\n\
! of range.");
  
  PyDoc_STRVAR(ExcNotSupportedError_doc,
! "Exception raised when a missing or not supported feature is being used.\n\n\
! Raised when trying to rollback a transaction on a database which doesn't\n\
! support transactions or when the database doesn't support a particular feature\n\
! (e.g. VARCHARs or BYTE/TEXT types on Informix SE).");
  
  /* Checks for occurance of database errors and handles them.
--- 152,163 ----
  PyDoc_STRVAR(ExcDataError_doc,
  "Exception raised for errors that occur due to the processed data.\n\n\
! Raised e.g. for a division by zero error or when a numeric value\n\
! is out of range.");
  
  PyDoc_STRVAR(ExcNotSupportedError_doc,
! "Exception raised for trying to use a missing or unsupported feature.\n\n\
! Raised when trying to rollback a transaction on a database which\n\
! doesn't support transactions or when the database doesn't support a\n\
! particular feature (e.g. VARCHARs or BYTE/TEXT types on Informix SE).");
  
  /* Checks for occurance of database errors and handles them.
***************
*** 242,247 ****
  "close()\n\n\
  Close the cursor now.\n\n\
! The cursor will be unusable from this point forward. Any operations on it\n\
! will raise an `InterfaceError`");
  
  PyDoc_STRVAR(Cursor_execute_doc,
--- 247,252 ----
  "close()\n\n\
  Close the cursor now.\n\n\
! The cursor will be unusable from this point forward. Any\n\
! operations on it will raise an `InterfaceError`");
  
  PyDoc_STRVAR(Cursor_execute_doc,
***************
*** 249,299 ****
  Execute an arbitrary SQL statement.\n\n\
  `operation` is a string containing the SQL statements with optional\n\
! placeholders, where either ``qmark``-style (``SELECT * FROM names WHERE name = ?``)\n\
! or ``numeric``-style (``SELECT * FROM names WHERE name = :1``) can be used.\n\
  \n\
! `seq_of_parameters` is a sequence of values to be bound to the placeholders in\n\
! the SQL statement. The number of values in the sequence must match the number\n\
! of parameters required by the SQL statement exactly. The types which are used\n\
! for binding are automatically derived from the Python types. For strings and\n\
! integers this is straightforward. To be able to bind date, time and binary\n\
! (``BYTE``/``TEXT``) values the module provides the constructors `Date`,\n\
! `Time`, `Timestamp`, `Binary` and some more to construct date and time\n\
! values from UNIX ticks.\n\n\
! Be careful when trying to pass in a single string for `seq_of_parameters`,\n\
! because it would be interpreted as a sequence. To get what is most likely\n\
! the desired effect you have to wrap it in a tuple, e.g.:\n\
  \n\
! >>> cursor.execute('SELECT * FROM names WHERE first = :1', 'donald')\n\
  Traceback (most recent call last):\n\
    File \"<stdin>\", line 1, in ?\n\
  _informixdb.InterfaceError: too many actual parameters\n\
! >>> cursor.execute('SELECT * FROM names WHERE first = :1', ('donald',))\n\
  \n"
! ":Note: Informix DB implements the operation-caching optimization. This\n\
!        means that passing the same operation object to the same `Cursor`\n\
!        object's `execute` method multiple times in a row will prepare the\n\
!        statement only once. This may result in a significant improvement in\n\
!        execution speed when the same statement is executed many times with\n\
!        different parameters.\n\
  \n\
! :Returns: `execute` will return the number of affected rows for statements\n\
!           which modify data, ``-1`` where the number of affected rows cannot\n\
!           be determined or `None` for statements which return a result set.\n\
!           As the behaviour of the return value is not specified in the DB-API 2.0\n\
!           specification you are best advised using `rowcount` to determine\n\
!           the number of affected rows, as this will provide the same information\n\
            in a standards compliant way.");
  
  PyDoc_STRVAR(Cursor_executemany_doc,
  "executemany(operation, seq_of_parameters)\n\n\
! Execute an arbitrary SQL statement multiple times using different parameters.\n\n\
! The `operation` parameter is the same as for `execute`, `seq_of_parameters` is a\n\
! sequence of parameter tuples (or more generally sequences) suitable for passing\n\
! to `execute`. This will invoke `execute` for all parameter sequences in\n\
! `seq_of_parameters`, but will still be fast since the operation is prepared only\n\
! once.\n\n\
! For batch inserts a special optimization applies, which will make use of\n\
! insert cursors. This can result in a huge speed increase compared to calling\n\
! `execute` multiple times, especially when used over a network.\n\
  \n\
  :Seealso: `execute`");
--- 254,314 ----
  Execute an arbitrary SQL statement.\n\n\
  `operation` is a string containing the SQL statements with optional\n\
! placeholders, where either ``qmark``-style\n\
! (``SELECT * FROM names WHERE name = ?``) or ``numeric``-style\n\
! (``SELECT * FROM names WHERE name = :1``) can be used.\n\
  \n\
! `seq_of_parameters` is a sequence of values to be bound to the\n\
! placeholders in the SQL statement. The number of values in the\n\
! sequence must match the number of parameters required by the SQL\n\
! statement exactly. The types which are used for binding are\n\
! automatically derived from the Python types. For strings and\n\
! integers this is straightforward. To be able to bind date, time\n\
! and binary (``BYTE``/``TEXT``) values the module provides the\n\
! constructors `Date`, `Time`, `Timestamp`, `Binary` and some more\n\
! to construct date and time values from UNIX ticks.\n\
  \n\
! Be careful when trying to pass in a single string for\n\
! `seq_of_parameters`, because it would be interpreted as a\n\
! sequence. To get what is most likely the desired effect you have\n\
! to wrap it in a tuple, e.g.:\n\
! \n\
! >>> cursor.execute('SELECT * FROM names WHERE first=:1', 'joe')\n\
  Traceback (most recent call last):\n\
    File \"<stdin>\", line 1, in ?\n\
  _informixdb.InterfaceError: too many actual parameters\n\
! >>> cursor.execute('SELECT * FROM names WHERE first=:1', ('joe',))\n\
  \n"
! ":Note: Informix DB implements the operation-caching optimization.\n\
!         This means that passing the same operation object to the\n\
!         same `Cursor` object's `execute` method multiple times in a\n\
!         row will prepare the statement only once. This may result\n\
!         in a significant improvement in execution speed when the\n\
!         same statement is executed many times with different\n\
!         parameters.\n\
  \n\
! :Returns: `execute` will return the number of affected rows for\n\
!           statements which modify data, ``-1`` where the number of\n\
!           affected rows cannot be determined or `None` for statements\n\
!           which return a result set. As the behaviour of the return\n\
!           value is not specified in the DB-API 2.0 specification you\n\
!           are best advised using `rowcount` to determine the number\n\
!           of affected rows, as this will provide the same information\n\
            in a standards compliant way.");
  
  PyDoc_STRVAR(Cursor_executemany_doc,
  "executemany(operation, seq_of_parameters)\n\n\
! Execute an arbitrary SQL statement multiple times using different\n\
! parameters.\n\
! \n\
! The `operation` parameter is the same as for `execute`,\n\
! `seq_of_parameters` is a sequence of parameter tuples (or more\n\
! generally sequences) suitable for passing to `execute`. This will\n\
! invoke `execute` for all parameter sequences in `seq_of_parameters`,\n\
! but will still be fast since the operation is prepared only once.\n\
! \n\
! For batch inserts a special optimization applies, which will make\n\
! use of insert cursors. This can result in a huge speed increase\n\
! compared to calling `execute` multiple times, especially when used\n\
! over a network.\n\
  \n\
  :Seealso: `execute`");
***************
*** 302,319 ****
  "fetchone() -> sequence\n\n\
  Fetch the next row of a query result set.\n\n\
! The next row is returned either as sequence or as mapping, depending on how\n\
! the `Cursor` was created (see `Connection.cursor`). When no more rows are\n\
! are available `None` is returned.\n\n\
! Calling `fetchone` when no statement was executed or after a statement that\n\
! does not produce a result set was executed will raise an Error.");
  
  PyDoc_STRVAR(Cursor_fetchmany_doc,
  "fetchmany([size=Cursor.arraysize]) -> list\n\n\
  Fetch a specified number of rows of a query result set.\n\n\
! Return up to `size` rows in a list, or fewer if there are no more rows\n\
! available. An empty list is returned if no row is available.\n\
  \n\
! The types of the rows and the behaviour in error cases is the same as for\n\
! `fetchone`.");
  
  PyDoc_STRVAR(Cursor_fetchall_doc,
--- 317,336 ----
  "fetchone() -> sequence\n\n\
  Fetch the next row of a query result set.\n\n\
! The next row is returned either as sequence or as mapping,\n\
! depending on how the `Cursor` was created (see\n\
! `Connection.cursor`). When no more rows are are available\n\
! `None` is returned.\n\n\
! Calling `fetchone` when no statement was executed or after\n\
! a statement that does not produce a result set was executed\n\
! will raise an Error.");
  
  PyDoc_STRVAR(Cursor_fetchmany_doc,
  "fetchmany([size=Cursor.arraysize]) -> list\n\n\
  Fetch a specified number of rows of a query result set.\n\n\
! Return up to `size` rows in a list, or fewer if there are no more\n\
! rows available. An empty list is returned if no row is available.\n\
  \n\
! The types of the rows and the behaviour in error cases is the same\n\
! as for `fetchone`.");
  
  PyDoc_STRVAR(Cursor_fetchall_doc,
***************
*** 323,328 ****
  empty list if there are no more rows available.\n\
  \n\
! The types of the rows and the behaviour in error cases is the same as for\n\
! `fetchone`.");
  
  PyDoc_STRVAR(Cursor_setinputsizes_doc,
--- 340,345 ----
  empty list if there are no more rows available.\n\
  \n\
! The types of the rows and the behaviour in error cases is the same\n\
! as for `fetchone`.");
  
  PyDoc_STRVAR(Cursor_setinputsizes_doc,
***************
*** 339,354 ****
  "callproc(procname[,parameters]) -> sequence\n\n\
  Execute a stored procedure.\n\n\
! Call the stored procedure `procname` with parameters as given in the sequence\n\
! `parameters`. This is preferable to `execute` with an ``EXECUTE PROCEDURE ...``\n\
! statement in most cases, because it should also work with other DB-API 2.0\n\
! implementations.\n\
  \n\
! If the stored procedure generates a result set it can be accessed through the\n\
! standard fetch methods.\n\
  \n\
! :Returns: The unmodified input sequence, because Informix doesn't support ``out``\n\
!           or ``in/out`` arguments on stored procedures (the specification says\n\
!           that a copy of the input sequence should be returned, where ``out``\n\
!           and ``in/out`` arguments are replaced by their new values).\n\
  ");
  
--- 356,372 ----
  "callproc(procname[,parameters]) -> sequence\n\n\
  Execute a stored procedure.\n\n\
! Call the stored procedure `procname` with parameters as given in\n\
! the sequence `parameters`. This is preferable to `execute` with an\n\
! ``EXECUTE PROCEDURE ...`` statement in most cases, because it\n\
! should also work with other DB-API 2.0 implementations.\n\
  \n\
! If the stored procedure generates a result set it can be accessed\n\
! through the standard fetch methods.\n\
  \n\
! :Returns: The unmodified input sequence, because Informix doesn't\n\
!           support ``out`` or ``in/out`` arguments on stored\n\
!           procedures (the specification says that a copy of the\n\
!           input sequence should be returned, where ``out`` and\n\
!           ``in/out`` arguments are replaced by their new values).\n\
  ");
  
***************
*** 375,378 ****
--- 393,405 ----
  };
  
+ PyDoc_STRVAR(Cursor_messages_doc,
+ "List of SQL warning and error messages.\n\n\
+ :Seealso: `Connection.messages`");
+ 
+ PyDoc_STRVAR(Cursor_errorhandler_doc,
+ "Python callable which is invoked for SQL errors.\n\n\
+ :Seealso: `Connection.errorhandler`"
+ );
+ 
  static PyMemberDef Cursor_members[] = {
    { "description", T_OBJECT_EX, offsetof(Cursor, description), READONLY,
***************
*** 383,389 ****
      "Number of rows to fetch in fetchmany." },
    { "messages", T_OBJECT_EX, offsetof(Cursor, messages), READONLY,
!     "List of SQL warning and error messages." },
    { "errorhandler", T_OBJECT_EX, offsetof(Cursor, errorhandler), 0,
!     "Python callable which is invoked for SQL errors." },
    { "connection", T_OBJECT_EX, offsetof(Cursor, conn), 0,
      "Database connection associated with this cursor." },
--- 410,416 ----
      "Number of rows to fetch in fetchmany." },
    { "messages", T_OBJECT_EX, offsetof(Cursor, messages), READONLY,
!     Cursor_messages_doc }, 
    { "errorhandler", T_OBJECT_EX, offsetof(Cursor, errorhandler), 0,
!     Cursor_errorhandler_doc },
    { "connection", T_OBJECT_EX, offsetof(Cursor, conn), 0,
      "Database connection associated with this cursor." },
***************
*** 393,397 ****
  static PyGetSetDef Cursor_getseters[] = {
    { "sqlerrd", (getter)Cursor_getsqlerrd, NULL,
!     "SQL error descriptor as tuple", NULL },
    { NULL }
  };
--- 420,424 ----
  static PyGetSetDef Cursor_getseters[] = {
    { "sqlerrd", (getter)Cursor_getsqlerrd, NULL,
!     "Informix SQL error descriptor as tuple", NULL },
    { NULL }
  };
***************
*** 399,425 ****
  PyDoc_STRVAR(Cursor_doc,
  "Executes SQL statements and fetches their results.\n\n\
! `Cursor` objects are the central objects in interacting with the database\n\
! since they provide the methods necessary to execute SQL statements and fetch\n\
! results from the database.\n\
  \n\
  To create a `Cursor` object call `Connection.cursor`.\n\
  \n\
! You can then use the `execute`, `executemany` and `callproc` methods to issue\n\
! SQL statements and get their results with `fetchone`, `fetchmany`, `fetchall`\n\
! or by iterating over the `Cursor` object.\n\
  \n\
! :Note: Iterating over a `Cursor` object is an extension to the DB-API 2.0\n\
!        specification.\n\
  \n\
! :Note: As an extension to the DB-API 2.0 specification Informix DB provides\n\
!        named cursors which allow you to use the ``... WHERE CURRENT OF ...``\n\
!        clause in your SQL statements. For information on how to use them see\n\
!        the `Connection.cursor` documentation.\n\
  \n\
! :Note: `Cursor` objects do not directly map to underlying database cursors.\n\
!        Actual database cursors are created in `execute`, `executemany` or\n\
!        `callproc` when needed (i.e. for ``SELECT`` and ``EXECUTE PROCEDURE``\n\
!        statements) and closed upon the next invocation of `execute`,\n\
!        `executemany` or `callproc` or when the `Cursor` object is deallocated.");
  
  static PyTypeObject Cursor_type = {
--- 426,454 ----
  PyDoc_STRVAR(Cursor_doc,
  "Executes SQL statements and fetches their results.\n\n\
! `Cursor` objects are the central objects in interacting with the\n\
! database since they provide the methods necessary to execute SQL\n\
! statements and fetch results from the database.\n\
  \n\
  To create a `Cursor` object call `Connection.cursor`.\n\
  \n\
! You can then use the `execute`, `executemany` and `callproc` methods\n\
! to issue SQL statements and get their results with `fetchone`,\n\
! `fetchmany`, `fetchall` or by iterating over the `Cursor` object.\n\
  \n\
! :Note: Iterating over a `Cursor` object is an extension to the\n\
!        DB-API 2.0 specification.\n\
  \n\
! :Note: As an extension to the DB-API 2.0 specification Informix DB\n\
!        provides named cursors which allow you to use the\n\
!        ``... WHERE CURRENT OF ...`` clause in your SQL statements.\n\
!        For information on how to use them see the `Connection.cursor`\n\
!        documentation.\n\
  \n\
! :Note: `Cursor` objects do not directly map to underlying database\n\
!        cursors. Actual database cursors are created in `execute`,\n\
!        `executemany` or `callproc` when needed (i.e. for ``SELECT``\n\
!        and ``EXECUTE PROCEDURE`` statements) and closed upon the\n\
!        next invocation of `execute`, `executemany` or `callproc` or\n\
!        when the `Cursor` object is deallocated.");
  
  static PyTypeObject Cursor_type = {
***************
*** 493,513 ****
  
  PyDoc_STRVAR(Connection_cursor_doc,
! "cursor([name=None,rowformat=informixdb.ROW_AS_TUPLE]) -> Cursor\n\n\
  Return a new `Cursor` object using the connection.\n\
- \n\n\
- `name` is an extension to the DB-API 2.0 specification and allows you to\n\
- optionally name your cursor. This is only useful when the cursor is going\n\
- to be used in ``'WHERE CURRENT OF <name>'`` clauses in SQL statements.\n\
- Note however, that you will have to use a second `Cursor` object to perform\n\
- the operation, since trying to execute the ``'... WHERE CURRENT OF ...'`` statement\n\
- with the named `Cursor` object itself will close it.\n\
  \n\
! `rowformat` is an extension to the DB-API 2.0 specification that can be used\n\
! to specify that dictionaries with the column names as keys should be used as\n\
! return values of `Cursor.fetchone`, `Cursor.fetchmany` and `Cursor.fetchall`\n\
! instead of tuples. To select this behaviour use `informixdb.ROW_AS_DICT` for\n\
! `rowformat`, e.g.:\n\
  \n\
! >>> cursor = conn.cursor(rowformat=informixdb.ROW_AS_DICT)\n\
  >>> cursor.execute('SELECT * FROM names')\n\
  >>> cursor.fetchall()\n\
--- 522,544 ----
  
  PyDoc_STRVAR(Connection_cursor_doc,
! "cursor([name=None,rowformat=_informixdb.ROW_AS_TUPLE]) -> Cursor\n\n\
  Return a new `Cursor` object using the connection.\n\
  \n\
! `name` is an extension to the DB-API 2.0 specification and allows\n\
! you to optionally name your cursor. This is only useful when the\n\
! cursor is going to be used in ``'WHERE CURRENT OF <name>'`` clauses\n\
! in SQL statements. Note however, that you will have to use a second\n\
! `Cursor` object to perform the operation, since trying to execute\n\
! the ``'... WHERE CURRENT OF ...'`` statement with the named `Cursor`\n\
! object itself will close it.\n\
  \n\
! `rowformat` is an extension to the DB-API 2.0 specification that\n\
! can be used to specify that dictionaries with the column names as\n\
! keys should be used as return values of `Cursor.fetchone`,\n\
! `Cursor.fetchmany` and `Cursor.fetchall` instead of tuples. To\n\
! select this behaviour use `_informixdb.ROW_AS_DICT` for `rowformat`,\n\
! e.g.:\n\
! \n\
! >>> cursor = conn.cursor(rowformat=_informixdb.ROW_AS_DICT)\n\
  >>> cursor.execute('SELECT * FROM names')\n\
  >>> cursor.fetchall()\n\
***************
*** 518,539 ****
  "commit()\n\n\
  Commit the current database transaction and start a new one.\n\n\
! `commit` does nothing for databases which have transactions disabled.");
  
  PyDoc_STRVAR(Connection_rollback_doc,
  "rollback()\n\n\
  Rollback the current database transaction and start a new one.\n\n\
! `rollback` raises a NotSupportedError for databases which have transactions\n\
! disabled");
  
  PyDoc_STRVAR(Connection_close_doc,
  "close()\n\n\
  Close the connection and all associated `Cursor` objects.\n\n\
! This is automatically done when the `Connection` object and all its associated\n\
! cursors are destroyed.\n\n\
! After the connection is closed it becomes unusable and all operations on it\n\
! or its associated `Cursor` objects will raise an InterfaceError.\n\n\
! For databases which have transactions enabled an implicit rollback is\n\
! performed before the closing the connection, so be sure to commit any\n\
! outstanding operations before closing a `Connection`.");
  
  static PyMethodDef Connection_methods[] = {
--- 549,572 ----
  "commit()\n\n\
  Commit the current database transaction and start a new one.\n\n\
! `commit` does nothing for databases which have transactions\n\
! disabled.");
  
  PyDoc_STRVAR(Connection_rollback_doc,
  "rollback()\n\n\
  Rollback the current database transaction and start a new one.\n\n\
! `rollback` raises a NotSupportedError for databases which have\n\
! transactions disabled.");
  
  PyDoc_STRVAR(Connection_close_doc,
  "close()\n\n\
  Close the connection and all associated `Cursor` objects.\n\n\
! This is automatically done when the `Connection` object and all\n\
! its associated cursors are destroyed.\n\n\
! After the connection is closed it becomes unusable and all\n\
! operations on it or its associated `Cursor` objects will raise\n\
! an InterfaceError.\n\n\
! For databases which have transactions enabled an implicit rollback\n\
! is performed before the closing the connection, so be sure to\n\
! commit any outstanding operations before closing a `Connection`.");
  
  static PyMethodDef Connection_methods[] = {
***************
*** 550,558 ****
  
  PyDoc_STRVAR(Connection_messages_doc,
! "A list with one ``(exception_class, exception_values)`` tuple for each error/warning.\n\n\
! The default `errorhandler` appends any warnings or errors concerning the\n\
! connection to this list. The list is automatically cleared by all connection\n\
! methods and can be manually cleared by the user with ``del connection.messages[:]``.\n\n\
! The purpose of these list is to eliminate the need to raise Warning exceptions.\n\n\
  :Note: This is an extension to the DB-API 2.0 specification.");
  
--- 583,594 ----
  
  PyDoc_STRVAR(Connection_messages_doc,
! "A list with one ``(exception_class, exception_values)`` tuple for\n\
! each error/warning.\n\n\
! The default `errorhandler` appends any warnings or errors\n\
! concerning the connection to this list. The list is automatically\n\
! cleared by all connection methods and can be manually cleared by\n\
! the user with ``del connection.messages[:]``.\n\n\
! The purpose of these list is to eliminate the need to raise\n\
! Warning exceptions.\n\n\
  :Note: This is an extension to the DB-API 2.0 specification.");
  
***************
*** 560,567 ****
  "An optional callable which can be used to customize error reporting.\n\n\
  `errorhandler` can be set to a callable of the form\n\
! ``errorhandler(connection, cursor, errorclass, errorvalue)`` and will be\n\
! called for any errors or warnings concerning the connection.\n\n\
! The default (if errorhandler is None) is to append the error/warning to the\n\
! `messages` list and raise an exception unless the errorclass is `Warning`.\n\n\
  :Note: This is an extension to the DB-API 2.0 specification.");
  
--- 596,605 ----
  "An optional callable which can be used to customize error reporting.\n\n\
  `errorhandler` can be set to a callable of the form\n\
! ``errorhandler(connection, cursor, errorclass, errorvalue)``\n\
! and will be called for any errors or warnings concerning the\n\
! connection.\n\n\
! The default (if errorhandler is None) is to append the error/warning\n\
! to the `messages` list and raise an exception unless the\n\
! errorclass is `Warning`.\n\n\
  :Note: This is an extension to the DB-API 2.0 specification.");
  
***************
*** 606,617 ****
  PyDoc_STRVAR(Connection_doc,
  "Connection to an Informix database.\n\n\
! Provides access to transactions and allows the creation of Cursor objects\n\
! via the `cursor` method.\n\n\
! As an extension to the DB-API 2.0 specification Informix DB provides the\n\
! exception classes as attributes of `Connection` objects in addition to the\n\
! module level attributes to simplify error handling in multi-connection\n\
! environments.\n\n\
! :Note: Do not instantiate objects of this class directly. Use \
! the `informixdb.connect` method instead.");
  
  static PyTypeObject Connection_type = {
--- 644,655 ----
  PyDoc_STRVAR(Connection_doc,
  "Connection to an Informix database.\n\n\
! Provides access to transactions and allows the creation of Cursor\n\
! objects via the `cursor` method.\n\n\
! As an extension to the DB-API 2.0 specification Informix DB provides\n\
! the exception classes as attributes of `Connection` objects in addition\n\
! to the module level attributes to simplify error handling in\n\
! multi-connection environments.\n\n\
! :Note: Do not instantiate objects of this class directly. Use the\n\
!        `_informixdb.connect` method instead.");
  
  static PyTypeObject Connection_type = {
***************
*** 2441,2496 ****
  "connect(dsn[,user,password]) -> Connection\n\n\
  Establish a connection to a database.\n\n\
! `dsn` identifies a database environment as accepted by the CONNECT statement.\n\
! It can be the name of a database (``'stores7'``) the name of a database server\n\
! (``'@valley'``) or a combination thereof (``'stores7@valley'``).");
  
  PyDoc_STRVAR(db_Date_doc,
  "Date(year,month,day) -> datetime.date\n\n\
! Construct an object holding a date value");
  
  PyDoc_STRVAR(db_Time_doc,
  "Time(hour,minute,second[,microsecond=0]) -> datetime.datetime\n\n\
! Construct an object holding a time value\n\n\
! Note that `microsecond` is an extension to the DB-API specification. It\n\
! represents the fractional part of an Informix DATETIME column, and is\n\
! therefore limited to a maximum of 10 microseconds of accuracy.");
  
  PyDoc_STRVAR(db_Timestamp_doc,
  "Timestamp(year,month,day,hour=0,minute=0,second=0,microsecond=0) -> datetime.datetime\n\n\
! Construct an object holding a time stamp (datetime) value\n\n\
! Note that `microsecond` is an extension to the DB-API specification. It\n\
! represents the fractional part of an Informix DATETIME column, and is\n\
! therefore limited to a maximum of 10 microseconds of accuracy.");
  
  PyDoc_STRVAR(db_TimestampFromTicks_doc,
  "TimestampFromTicks(ticks) -> datetime.datetime\n\n\
! Construct an object holding a time stamp (datetime) from the given ticks value\n\n\
  `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\
! Note that using ticks might cause problems, because they cover only a limited\n\
! time range. See the standard Python time and datetime modules' documentation\n\
! for details.");
  
  PyDoc_STRVAR(db_DateFromTicks_doc,
  "DateFromTicks(ticks) -> datetime.date\n\n\
! Construct an object holding a date value from the given ticks value\n\n\
  `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\
! Note that using ticks might cause problems, because they cover only a limited\n\
! time range. See the standard Python time and datetime modules' documentation\n\
! for details.");
  
  PyDoc_STRVAR(db_TimeFromTicks_doc,
  "TimeFromTicks(ticks) -> datetime.datetime\n\n\
! Construct an object holding a time value from the given ticks value\n\n\
  `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\
! Note that using ticks might cause problems, because they cover only a limited\n\
! time range. See the standard Python time and datetime modules' documentation\n\
! for details.");
  
  PyDoc_STRVAR(db_Binary_doc,
  "Binary(string) -> buffer\n\n\
! Construct an object capable of holding a binary (long) value");
  
  static PyMethodDef globalMethods[] = {
--- 2479,2538 ----
  "connect(dsn[,user,password]) -> Connection\n\n\
  Establish a connection to a database.\n\n\
! `dsn` identifies a database environment as accepted by the CONNECT\n\
! statement. It can be the name of a database (``'stores7'``) the name\n\
! of a database server (``'@valley'``) or a combination thereof\n\
! (``'stores7@valley'``).");
  
  PyDoc_STRVAR(db_Date_doc,
  "Date(year,month,day) -> datetime.date\n\n\
! Construct an object holding a date value.");
  
  PyDoc_STRVAR(db_Time_doc,
  "Time(hour,minute,second[,microsecond=0]) -> datetime.datetime\n\n\
! Construct an object holding a time value.\n\n\
! :Note: `microsecond` is an extension to the DB-API specification. It\n\
!        represents the fractional part of an Informix DATETIME column,\n\
!        and is therefore limited to a maximum of 10 microseconds of\n\
!        accuracy.");
  
  PyDoc_STRVAR(db_Timestamp_doc,
  "Timestamp(year,month,day,hour=0,minute=0,second=0,microsecond=0) -> datetime.datetime\n\n\
! Construct an object holding a time stamp (datetime) value.\n\n\
! :Note: `microsecond` is an extension to the DB-API specification. It\n\
!        represents the fractional part of an Informix DATETIME column,\n\
!        and is therefore limited to a maximum of 10 microseconds of\n\
!        accuracy.");
  
  PyDoc_STRVAR(db_TimestampFromTicks_doc,
  "TimestampFromTicks(ticks) -> datetime.datetime\n\n\
! Construct an object holding a time stamp (datetime) from the given\n\
! ticks value.\n\n\
  `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\n\
! :Note: Using ticks might cause problems, because they cover only a\n\
!        limited time range. See the standard Python `time` and `datetime`\n\
!        modules' documentation for details.");
  
  PyDoc_STRVAR(db_DateFromTicks_doc,
  "DateFromTicks(ticks) -> datetime.date\n\n\
! Construct an object holding a date value from the given ticks value.\n\n\
  `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\n\
! :Note: Using ticks might cause problems, because they cover only a\n\
!        limited time range. See the standard Python `time` and `datetime`\n\
!        modules' documentation for details.");
  
  PyDoc_STRVAR(db_TimeFromTicks_doc,
  "TimeFromTicks(ticks) -> datetime.datetime\n\n\
! Construct an object holding a time value from the given ticks value.\n\n\
  `ticks` are the number of seconds since the start of the current epoch\n\
! (1.1.1970 for UNIX).\n\n\
! :Note: Using ticks might cause problems, because they cover only a\n\
!        limited time range. See the standard Python `time` and `datetime`\n\
!        modules' documentation for details.");
  
  PyDoc_STRVAR(db_Binary_doc,
  "Binary(string) -> buffer\n\n\
! Construct an object capable of holding a binary (long) value.");
  
  static PyMethodDef globalMethods[] = {
***************
*** 2515,2521 ****
  
  PyDoc_STRVAR(_informixdb_doc,
! "DB-API 2.0 compliant database interface for Informix databases.\n\
  \n\
! To get you started while the documentation gets written (don't wait!):\n\
  \n\
  >>> import informixdb\n\
--- 2557,2563 ----
  
  PyDoc_STRVAR(_informixdb_doc,
! "`DB-API 2.0`_ compliant interface for Informix databases.\n\
  \n\
! To get you started:\n\
  \n\
  >>> import informixdb\n\
***************
*** 2526,2529 ****
--- 2568,2573 ----
  [('donald', 'duck', 34), ('mickey', 'mouse', 23)]\n\
  \n\
+ .. _DB-API 2.0: http://www.python.org/peps/pep-0249.html\n\
+ \n\
  :Note: Informix DB uses the `datetime` module to represent date, time and\n\
         timestamp values. It is part of the standard library since\n\
***************
*** 2548,2552 ****
  #define defException(name, base) \
            do { \
!             PyObject* d = Py_BuildValue("{ss}", "__doc__", Exc##name##_doc); \
              Exc##name = PyErr_NewException("_informixdb."#name, base, d); \
              Py_DECREF(d); \
--- 2592,2598 ----
  #define defException(name, base) \
            do { \
!             PyObject* d = Py_BuildValue("{sssssisN}", "__doc__", Exc##name##_doc,\
!                                         "action", "", "sqlcode", 0,\
!                                         "diagnostics", PyList_New(0)); \
              Exc##name = PyErr_NewException("_informixdb."#name, base, d); \
              Py_DECREF(d); \

[Informixdb-cvs] informixdb setup.py,1.5,1.6

From: Carsten H. <ch...@us...> - 2005-10-18 05:09:09

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31522

Modified Files:
	setup.py 
Log Message:
Only invoke esql if _informixdb.ec is newer than extension.
Print helpful error message if esql can't be found.


Index: setup.py
===================================================================
RCS file: /cvsroot/informixdb/informixdb/setup.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** setup.py	18 Oct 2005 03:26:36 -0000	1.5
--- setup.py	18 Oct 2005 05:09:00 -0000	1.6
***************
*** 7,10 ****
--- 7,12 ----
  from distutils.util import get_platform
  from distutils.command.build_ext import build_ext as _build_ext
+ from distutils.dep_util import newer_group
+ from distutils.errors import *
  
  class build_ext(_build_ext):
***************
*** 68,72 ****
              token = token[1:-1]
            esql_config.append(token)
!         cout.close()
  
          if get_platform()=="win32":
--- 70,77 ----
              token = token[1:-1]
            esql_config.append(token)
!         ret = cout.close()
!         if ret != None:
!           raise DistutilsSetupError, \
!                 "\nCan't find esql. Please set INFORMIXDIR correctly."
  
          if get_platform()=="win32":
***************
*** 98,101 ****
--- 103,114 ----
  
      def build_extension(self, ext):
+         # only preprocess with esql if necessary
+         fullname = self.get_ext_fullname(ext.name)
+         ext_filename = os.path.join(self.build_lib,
+                                         self.get_ext_filename(fullname))
+         if not (self.force or newer_group(ext.sources, ext_filename, 'newer')):
+             self.announce("skipping '%s' extension (up-to-date)" % ext.name)
+             return
+ 
          # preprocess *.ec files with 'esql'
          for file in ext.sources:

[Informixdb-cvs] informixdb setup.py,1.4,1.5

From: Carsten H. <ch...@us...> - 2005-10-18 03:26:48

Update of /cvsroot/informixdb/informixdb
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14846

Modified Files:
	setup.py 
Log Message:
Bump version number


Index: setup.py
===================================================================
RCS file: /cvsroot/informixdb/informixdb/setup.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** setup.py	18 Oct 2005 03:12:51 -0000	1.4
--- setup.py	18 Oct 2005 03:26:36 -0000	1.5
***************
*** 150,155 ****
  
  setup (name = 'InformixDB',
!        version = '1.4',
!        description = 'InformixDB v1.4',
         py_modules = modules,
         ext_modules = [module1],
--- 150,155 ----
  
  setup (name = 'InformixDB',
!        version = '2.0',
!        description = 'InformixDB v2.0',
         py_modules = modules,
         ext_modules = [module1],

[Informixdb-cvs] informixdb/ext _informixdb.ec,1.15,1.16

From: Carsten H. <ch...@us...> - 2005-10-18 03:16:49

Update of /cvsroot/informixdb/informixdb/ext
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12915

Modified Files:
	_informixdb.ec 
Log Message:
Win32 fixes: The compiler predefines _WIN32, not WIN32. Also, the
compiler doesn't like string literals over 2K long, but apparently it has
no problem with the concatenation that yields a >2K string constant.


Index: _informixdb.ec
===================================================================
RCS file: /cvsroot/informixdb/informixdb/ext/_informixdb.ec,v
retrieving revision 1.15
retrieving revision 1.16
diff -C2 -d -r1.15 -r1.16
*** _informixdb.ec	17 Oct 2005 20:10:09 -0000	1.15
--- _informixdb.ec	18 Oct 2005 03:16:41 -0000	1.16
***************
*** 40,44 ****
  #undef loc_t
  
! #ifdef WIN32
  #include <value.h>
  #include <sqlproto.h>
--- 40,44 ----
  #undef loc_t
  
! #ifdef _WIN32
  #include <value.h>
  #include <sqlproto.h>
***************
*** 269,274 ****
  _informixdb.InterfaceError: too many actual parameters\n\
  >>> cursor.execute('SELECT * FROM names WHERE first = :1', ('donald',))\n\
! \n\
! :Note: Informix DB implements the operation-caching optimization. This\n\
         means that passing the same operation object to the same `Cursor`\n\
         object's `execute` method multiple times in a row will prepare the\n\
--- 269,274 ----
  _informixdb.InterfaceError: too many actual parameters\n\
  >>> cursor.execute('SELECT * FROM names WHERE first = :1', ('donald',))\n\
! \n"
! ":Note: Informix DB implements the operation-caching optimization. This\n\
         means that passing the same operation object to the same `Cursor`\n\
         object's `execute` method multiple times in a row will prepare the\n\

Flat | Threaded

<< < 1 .. 5 6 7 8 > >> (Page 7 of 8)

2005	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (36)	Nov (40)	Dec (6)
2006	Jan (1)	Feb	Mar (6)	Apr (3)	May	Jun	Jul	Aug	Sep (13)	Oct (12)	Nov (10)	Dec (8)
2007	Jan	Feb (1)	Mar (1)	Apr	May	Jun (5)	Jul	Aug (1)	Sep (4)	Oct (15)	Nov	Dec (1)
2008	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug (2)	Sep (5)	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (4)	Dec
2012	Jan	Feb	Mar	Apr	May	Jun (3)	Jul	Aug	Sep	Oct	Nov	Dec