Am 29.05.2013 21:29, schrieb Ed Leafe:

> On May 22, 2013, at 7:28 AM, Sibylle

> Koczian<Sibylle.Koczian@t-online.de> wrote:

>

>> File "/home/sib/src/dabo-master/dabo/biz/dBizobj.py", line 300, in

>> __init__ apply(secondary.__init__, (self,) + args, kwargs)

>> TypeError: __init__() takes exactly 3 arguments (2 given)

>>

>> What is happening here? What is "secondary" and what is its

>> __init__ method?

>

> 'secondary' is the cursor class for the particular backend; in your

> case, Firebird. Apparently the Firebird cursor requires more than the

> standard arguments. Can you look at the kinterbasdb and/or fdb code

> to see what arguments are required for the cursor class's __init__()

> method?

>

I didn't find that code in the kinterbasdb package - could it be

contained in _kinterbasdb.so?

FDB: The arguments seem to be "connection" and "transaction" (and self,

of course). Could the "transaction" parameter be new?

class Cursor(object):

"""Represents a database cursor, which is used to execute SQL

statement and

manage the context of a fetch operation.

.. important::

DO NOT create instances of this class directly! Use only

:meth:`Connection.cursor`, :meth:`Transaction.cursor` and

:meth:`ConnectionGroup.cursor` to get Cursor instances that

operate in

desired context.

.. note::

Cursor is actually a high-level wrapper around

:class:`PreparedStatement`

instance(s) that handle the actual SQL statement execution and

result

management. Cursor has an internal cache of PreparedStatements,

so when

the same SQL statement is executed repeatedly, related

PreparedStatement

is re-used, which enhances performance. This convenient

enhancement has

a side effect: Cursor that was used to perform many different

SQL statements

may hold very large cache of PerapedStatements. To clear the

cache, you'll

need to call :meth:`clear_cache`.

.. tip::

Cursor supports the iterator protocol, yielding tuples of values

like

:meth:`fetchone`.

"""

#: (Read/Write) As required by the Python DB API 2.0 spec, the

value of this

#: attribute is observed with respect to the :meth:`fetchmany`

method. However,

#: changing the value of this attribute does not make any

difference in fetch

#: efficiency because the database engine only supports fetching a

single row

#: at a time.

arraysize = 1

def __init__(self, connection, transaction):

"""

.. important::

The association between a Cursor and its

:class:`Transaction` and

:class:`Connection` is set when the Cursor is created, and

cannot be

changed during the lifetime of that Cursor.

:param connection: :class:`Connection` instance this cursor

should be bound to.

:param transaction: :class:`Transaction` instance this cursor

should be bound to.

"""

self._prepared_statements = {}

self._connection = connection

self._transaction = transaction

self._ps = None # current prepared statement

Possibly this might be helpful (from the FDB documentation):

Distributed transactions

Support for Distributed Transactions works in slightly differently than

in KDB. FDB uses ConnectionGroup class like KDB with the same interface,

but DT is not bound to main transaction of individual connections

managed by group. That means that Cursor instances obtained from

Connection don’t work in DT if connection is part of ConnectionGroup,

but work normally in connection context. To get Cursor for specific

connection that works in DT, use fdb.ConnectionGroup.cursor() method and

pass the connection as parameter. We believe that this arrangement is

more logical and flexible than KDB’s way.

Transaction context for cursor objects depends on how cursor is

obtained/created:

fdb.Connection.cursor() - Works in context of “main” transaction

for connection.

fdb.Transaction.cursor() - Works in context of this transaction.

fdb.ConnectionGroup.cursor() - Works in context of Distributed

Transaction

Thank you,

Sibylle

_______________________________________________

Post Messages to: Dabo-users@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-users

Searchable Archives: http://leafe.com/archives/search/dabo-users

This message: http://leafe.com/archives/byMID/51A723E3.3040002@t-online.de