formix-ESQL
>> Version 4.10.UC9W1X1 + python-informixdb )
>> I do not see any update on https://github.com/amitkr/python-informixdb page
>> w.r.t CSDK/esql 4.1
Hi,
I don't actively support this module anymore, but I'll see what I can
do to h
On Fri, Oct 8, 2010 at 12:30 PM, Vivek Srivastav wrote:
> Hi Carsten,
> I know it's been a while since any development was done on InformixDB,
> however I wanted to see if you would have any idea on how to resolve. I
> would appreciate any pointers or help.
> Sincere Regards,
> Vivek
> I am trying
On Mon, Aug 24, 2009 at 4:00 AM, M. Hecht wrote:
>
> Hi,
>
> finally I got it working,
Congratulations!
> but have some questions left.
>
> The minimum configuration I need is to install INFORMIX and then to have
> the
> following seetings:
>
> set INFORMIXSERVER=myPreferredInformixServerName
On Fri, Aug 21, 2009 at 9:52 AM, M. Hecht wrote:
>
> Hmmm
>
> meanwhile I tried to find something in the proposed documentation but
> failed.
>
> What I have is a Network Address, Port, DB-Server-Name and DB-Name since on
> the computer are
> running several databases.
>
> This is what I trie
st in Python, because that's how the
Informix client library is set up.
> Is there any comparable approach doing this in one script whithout
> additional configuration?
You could try to set up the necessary environment directly in your code.
Good luck,
Carsten Haese
http://inf
2.ProgrammingError: Error. Party name normon not found in the
> party table.
>
> but if I put the "cur.execute" in a "try:" / "except:" I cannot figure out
> where to get the error text that I need,
> can anyone help please??
>
I don't have a PostgreSQL
ting this, but I don't see much use
for it myself.
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
ebound, it'll reference the same string
object as before, hence the cursor object may optimize its behavior by
reusing a previously prepared statement for that query instead of
re-preparing the statement.
HTH,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
about a dictionary as a
Python data structure or about a dictionary as a list of word
definitions/translations.
Please rephrase your question and provide more detail about what you
need to know, and maybe then we'll be able to help you.
--
Carsten Haese
http://informixdb.so
ecified API module for your unspecified database
engine uses question marks as parameter markers. Adjust the parameter marker
to %s if necessary.)
If the list comes from another table, you should probably use a sub-query or
rewrite your query to use a join
led in by
the dynamic linker according to ldd. What does "grep
sqli_describe_input_stmt /usr/local/informix/lib/esql/libifsql.so" show?
Hope this helps,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
ou compiled the
module? Is $INFORMIXDIR set to something different when you try to run
the module, and if so, what is it set to?
Thanks,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
01", "10001"))
descr10002 = informixdb.Binary("Description for catalog number 10002")
cur.execute("""
update catalog set cat_descr = ? where catalog_num = ?
""", (descr10002, "10002"))
binding of boolean parameters in WHERE clauses
- Make version information about server and client available
- Various bug fixes
Get the goods at http://informixdb.sourceforge.net
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
ecision.
Or you could just go with Informix and call it a day ;-)
HTH,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
comma delimiters.
Hope this helps,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
entire DB-SIG community. It's your right to post a proposal and ask for
a vote.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
hat's why we decided not too long ago to make qmark and named
mandatory in the next version of DB-API.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
e.
The sheer size of the problem of database abstraction and the fact that
there is no one solution that fits all is the reason why there are many
different solutions such as SQLObject, SQLAlchemy, Dabo, Django, etc
already in the wild. It's also the reason why I doubt that DB-API
u're encountering in
whatever it is you're doing that makes you feel that the existing way is
inadequate. Right now, you're coming off somewhat trollish by making
proposals for solving non-existent problems.
--
Carsten Haese
http://informixdb.sourceforge.net
On Sat, 2007-08-11 at 18:33 -0400, Mike Meyer wrote:
> On Sat, 11 Aug 2007 17:10:34 -0400 Carsten Haese <[EMAIL PROTECTED]> wrote:
> > The iron-clad, all-encompassing, golden rule is this: If something looks
> > like a parameter marker and occurs in a place where a pa
e SQL -
> including the table and column names in the definition - is getting
> built on the fly. I can see that if I were writing the queries by hand
> and knew all the table/column names in advance, none of this would
> matter. But I'm not, so it does.
Well, as you hopefully know
On Sat, 2007-08-11 at 04:25 -0400, Mike Meyer wrote:
> On Fri, 10 Aug 2007 20:24:17 -0400 Carsten Haese <[EMAIL PROTECTED]> wrote:
> > As I said, there is a defined way: Don't treat things that look like
> > parameter markers as parameter markers if they appear inside
urrent situation.
As I said, there is a defined way: Don't treat things that look like
parameter markers as parameter markers if they appear inside
apostrophes. This may require a simple parser in the API module, but I
prefer placing a burden on a dozen API module authors over placing a
burden
On Tue, 2007-08-07 at 21:37 -0400, Carsten Haese wrote:
> On Wed, 2007-08-08 at 00:40 +0200, Paul Boddie wrote:
> > On Tuesday 07 August 2007 19:17, Carsten Haese wrote:
> > > On Tue, 2007-08-07 at 11:58 -0500, Lukasz Szybalski wrote:
> > > >
> > > > W
On Tue, 2007-08-07 at 21:37 -0400, Carsten Haese wrote:
> [...] The standard way (at least as far as
> Informix understands it) is not to quote table/column names at all and
> let the parser worry about determining whether the word it's looking at
> is the name of a thing or a k
On Wed, 2007-08-08 at 00:40 +0200, Paul Boddie wrote:
> On Tuesday 07 August 2007 19:17, Carsten Haese wrote:
> > On Tue, 2007-08-07 at 11:58 -0500, Lukasz Szybalski wrote:
> > >
> > > When i do:
> > > insert into tablename(id,desc)VALUES(1,'some
On Tue, 2007-08-07 at 13:06 -0500, Lukasz Szybalski wrote:
> On 8/7/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-08-07 at 11:58 -0500, Lukasz Szybalski wrote:
> > > Hello,
> > > I have installed mysqldb python bindings and I am using python to
&g
sorting DESC
>
> When i do:
> insert into tablename(id,desc)VALUES(1,'some text')
>
> How do I escape 'desc'?
insert into tablename(id,`desc`) ...
HTH,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SI
us
what your database server is. Oracle, Sql server, Informix, PostgreSQL,
MySQL, ...?
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
gards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
and go with the
established semantics.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
implementation to be either non-compliant or not backwards compatible.
That would not be good, which is why additions to the spec are being
discussed this thoroughly.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-S
eaving the transaction block.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Thu, 2007-06-21 at 14:26 -0600, Anthony Tuininga wrote:
> On 6/21/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> > with api.connect(dbname) as conn:
> >with conn.cursor() as cur:
> > cur.execute(stmt)
>
> That's interesting but is it of muc
On Thu, 2007-06-21 at 14:30 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 11:51 -0500, Carl Karsten wrote:
> >> Carsten Haese wrote:
> >>> On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
> >>>> When we talk
rolled back, or
continued? If the engine underneath supports nested transactions, should
the with-statement's transaction enter a nested transaction?
Maybe the transaction() function should grow a parameter for specifying
this.
Regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Thu, 2007-06-21 at 11:51 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
> >> When we talk about backwards compatibility, I am wondering exactly what
> >> that means.
> >
> > A module is back
ve
> paramstyle changes.
If we make the change as proposed, and the modules implement the change
correctly, ALL v2-based application code out there will survive the
change. After all, that's what backwards compatibility means.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Thu, 2007-06-21 at 09:14 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
> >> Carsten Haese wrote:
> >>> The advantages are clear:
> >>>
> >>> * Application code written against t
On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > The advantages are clear:
> >
> > * Application code written against this spec can be sure that named/qmark
> > styles are available, and there is a common API for choosing which one to
&
y.
You're welcome to try to come up with a simpler solution that has the same
advantages.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
hould be pretty easy to wrap all the v3
> modules in a v2 conversion layer that will add the extra 'features' like
> pyformat.
And how is bolting on a conversion layer "super simple" compared to not
breaking backwards compatibility in the first place?
--
Carsten Haese
htt
On Wed, 2007-06-20 at 23:34 +0200, M.-A. Lemburg wrote:
> On 2007-06-20 23:15, Paul Boddie wrote:
> > On Wednesday 20 June 2007 22:51, Carsten Haese wrote:
> >> If I counted correctly, six votes were cast and the totals are:
> >>
> >> qmark 3
> &g
On Mon, 2007-06-04 at 16:32 +0200, M.-A. Lemburg wrote:
> On 2007-06-04 16:00, Carsten Haese wrote:
> >> So I'm:
> >>
> >> * +1 on making support one param style mandatory for all
> >>implementations
> >
> > Any one? Let's ma
ma for lists
> with more than 1 element).
Please read Marc-Andre's response to the original poster.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
sql1992.txt
You missed this on page 63:
"""
In SQL-statements that are executed
dynamically, the parameters are called dynamic parameters (s) and are represented in SQL language by a
(?).
"""
--
Carsten Haese
http://informixdb.sourceforge.net
_
%s', (items,))
> >resulting query string: SELECT * from table1 WHERE field1 IN ('1',)
>
> A bug in your Python-database bridge. It should handle sequences correctly.
Says who? As Marc-Andre pointed out, parameter binding is only for
scalar values.
--
Carsten Haese
http:
s
the best of both worlds.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Mon, 2007-06-04 at 19:09 +0200, M.-A. Lemburg wrote:
> On 2007-06-04 16:00, Carsten Haese wrote:
> >> What happens if you're in qmark style mode and the SQL statement
> >> contains substrings which look like named style (but are not
> >> intended tha
common style
mandatory, and allowing other styles as optional extensions.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
e doubled up, which is an ugly wart.
Regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Mon, 2007-06-04 at 16:32 +0200, M.-A. Lemburg wrote:
> On 2007-06-04 16:00, Carsten Haese wrote:
> >> So I'm:
> >>
> >> * +1 on making support one param style mandatory for all
> >>implementations
> >
> > Any one? Let's ma
nterface should look like.
> * -1 on doing auto-detection of param styles at .execute()
>call time based on parsing the SQL statement
I now agree with -1 on making auto-detection mandatory as long as there
is a way to turn it on. How about making a special paramstyle called
auto?
--
"the parameters argument may be any object with a
__getitem__ method that provides appropriate keys", so I'm fine with
either one as long as that gives us auto-detection of parameter styles.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
ng that the .execute()
signature depend on a connection/cursor attribute. I'm not sure that
that's much better than having it depend directly on the query string.
Regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG m
detection is
module.apilevel=='3.0'.
> There's also the problem of parameter type if we allow named
> style. The parameters would then have to be dictionaries for
> named and tuples for qmark/numeric. So you effectively change
> the signature of the .execute() methods
of c.execute()?
If you're parsing the query string, you already know which parameter
style the query uses.
> Only if I support other (nonstandard) styles will I really ever need
> to have someone specify
> which to expect.
What non-standard styles are you expect
On Sat, 2007-06-02 at 20:42 +0200, Paul Boddie wrote:
> Carsten Haese wrote:
> >
> > The same is true for InformixDB. The good news is that making a parser
> > that locates parameter placeholders is not hard. Essentially it boils
> > down to "Look for question marks
it's followed by a valid placeholder number or name, it's
a placeholder. Otherwise it's considered part of the SQL query.
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
t for your SQL dialect?" but I think we'll just have to
stipulate that the answer is yes.
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
d is IMO a bad idea.)
Then again, I'm not too excited about the whole idea of manual
switching. I'd prefer auto-detection based on whether the query string
contains question marks, colon+number or colon+identifier markers
outside of string literals. Not only because that
e two categories. im not sure if
> they look at the string itself or the given args (my guess is they
> look at the args being sent) but its totally doable.
I know auto-detect is doable, that's what InformixDB does. My point was
simply that you didn't specify your preference.
--
'm +0 on making it required. If it
were required, you'd have to specify how the API is expected to
differentiate between qmark and named. Do you expect the API to
auto-detect the parameter style from the query string, or do you expect
some kind of switching mechanism?
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
more involved. Something along these lines:
paramnames = [ ":p%d"%i for (i,_) in enumerate(cList) ]
paramdict = dict(zip(paramnames, cList))
cSql = ("select ktbl2_fk from tbl3 where OtherKey IN ("
+",".join(paramnames)
+")" )
cur.execute(cSql, paramdict)
HTH,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Wed, 2007-05-23 at 13:13 -0500, Carl Karsten wrote:
> list = rows
> cSql = ("select ktbl2_fk from tbl3 where ktbl1_fk IN ("
>+",".join("%s" for _ in list)
>+")" )
> print cSql
> cur.execute(cSql, list)
Assuming that "rows" is the fetchall() result from your first query, try
list = [x[0
lved, possibly of the kind I proposed before this thread was
hijacked. The problem could then be avoided by memoizing the result of
the adapter call, either in the adapter function itself or within the
DB-API layer.
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
it.next() or f.readline(), the dictionary stores the result, and that
result can be retrieved repeatedly without any problems.
[Footnote: The locals() idiom for emulating host variables is what
convinced me to implement named binding in the first place. For
programmers coming to Python
me, which it might,
since the cursor is being used like a prepared statement, so its name should
reflect what it does.
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
from server 2 into client memory, and do the reconciliation in client memory.
There is also Option 3: Use actual parameter passing to build a WHERE ... IN
(...) clause:
cSql = ("select ktbl2_fk from tbl3 where OtherKey IN ("
+",&qu
te a lot of parameters and readability is
> therefore valuable...
I agree, but named style, i.e. ":name" is even more readable, and it's
not as easily confused with string formatting.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
quot;not much" code is required, the
amount is greater than zero, for no obvious benefit. Even requiring
qmark may require non-trivial code additions to some existing API
modules, but I think the effort would be justified. Requiring numeric
and named as well just adds a gratuitous implementati
ursor attribute, or given as an optional
argument to execute(), should be encouraged, but not required.
This has been discussed before, but I'd like to re-cast a vote on this
for DB-API 3.0:
* Deprecate/disallow pyformat/format paramstyles.
* Make qmark the mandatory minimum paramstyle. Al
es, which is
precisely why my outputmap/inputmap mechanism is flexible enough to
handle a lot of different use case scenarios. But it also provides a
foundation for handling common use cases with standard typemaps that
have database-independent names and agreed-upon semantics.
Best regards,
--
Car
been corrected, thanks for bringing it to my
attention. Apparently your mail exchanger is on the same IP range as a
known spammer, and my sysadmin blocked the entire range without
realizing that he was throwing out the baby with the bathwater.]
Best regards,
--
Ca
Testing new subscription address since my other email account is blind
to mal's posts...
-Carsten
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
Testing new subscription address.
-Carsten
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
s a mind of
its own today.
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
hase approach avoids this.
"""
I think you misunderstand. The code you're quoting is for input binding,
not for output binding. True, it would have to be done for every value
passed as a parameter, but most python objects that a database is likely
to see will have a rather short MRO, and the pseudocode is just a
suggestion. The cursor could memoize the results of the lookup in case
the same query gets executed again with input parameters of the same
types. (And of course, memoization could also be done in the lookup for
output adapters.)
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
are to
reaching consensus, even if it's just a "show of hands" in the form of
+1/0/-1 responses.
Thanks in advance,
--
Carsten Haese
http://informixdb.sourceforge.net
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Thu, 2007-05-10 at 17:35 +0200, eGenix Team: M.-A. Lemburg wrote:
> [release announcement...]
Ah, that explains why you were conspicuously absent from the type
mapping discussion. I hope you'll have some time to chime in now ;)
Cheers,
--
Carsten Haese
http://informixdb.sourcef
On Wed, 2007-05-09 at 15:45 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Wed, 2007-05-09 at 14:57 -0500, Carl Karsten wrote:
> >> I need to read some data from an old system that is running on a 1999
> >> linux box.
> >> Using strings, I find:
>
re
doesn't seem to be a Python API, as if that's a surprise, but there are
a low-level ISAM API and a C API. With any luck, one of those APIs
should already be on that server. That might be enough to at least get a
data dump.
Good luck,
--
Carsten Haese
http://i
o. That way,
the developer will be able to write something like
conn.outputmap = somedb.DecimalAsFloat + somedb.CharAsUnicode
to combine two standard maps in a rather natural way.
I hope this makes sense,
--
Carsten Haese
http://informixdb.sourceforge.net
__
Viewing the API from the database
> is wrong in only the most subtle of ways.
The pre-established semantics disagree. I think it's better to stick to
those semantics than to confuse matters by adding another naming
convention such as import/export or fromdb/todb or fromapp/toapp.
Best regards
ation
> written in Python and may even need to written to a different DBMS.
> I see the role of the interface to make the data available in pure
> Python
> form. (So this argues against the proposal by Carsten Haese, I think.)
I agree, and I have changed my proposal significantly to remov
Hiya everybody,
I'd like to pick up the discussion on "Controlling return types" again.
I have incorporated feedback I received in response to my first type
mapping proposal into http://www.uniqsys.com/~carsten/typemap.html .
Comments are appreciated.
Best regards,
--
Car
On Wed, 2007-05-02 at 08:47 -0400, Art Protin wrote:
> [...]I find that there is
> some merit in getting the data, any of the data, as strings, which just
> happens to be the format that our database uses to pass them.
> Thus, there are two aspects where you could now influence my
> implementation:
On Sun, 2007-04-22 at 16:19 -0400, Jim Patterson wrote:
> On 4/21/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> In light of this development, I propose the following changes
> to my
> proposal:
> * The SQLData class and the ToDB interfa
On Sat, 2007-04-21 at 13:33 -0400, Michael Bayer wrote:
> On Apr 21, 2007, at 12:18 PM, Carsten Haese wrote:
> > Essentially, the proposed input translation could change to
> >
> > if hasattr(in_param, "ToDB"):
> > in_param = in_param.ToDB()
> >
&
On Sat, 2007-04-21 at 10:52 -0400, Michael Bayer wrote:
> On Apr 21, 2007, at 3:09 AM, Carsten Haese wrote:
>
> > Hi All,
> >
> > I have taken the time to write out my type mapping proposal in a
> > slightly more structured form, with some hopefully enlightening
Hi All,
I have taken the time to write out my type mapping proposal in a
slightly more structured form, with some hopefully enlightening examples
of how this proposal might be useful.
Please see http://www.uniqsys.com/~carsten/typemap.html
Any comments are welcome, and I'll do my best to incorpo
Now that it's the weekend, I'd like to chime in. I had been thinking for
a while now about type conversions from the Informix angle. Since
Informix allows user-defined types, I'd like to implement a type
conversion scheme that is flexible enough to allow specifying type
conversions for any data typ
: SQLCODE -201 in PREPARE:
42000: Syntax error or access violation
If you want true cross-database compatibility, you should use an
ORM/abstraction layer like SQLObject or SQLAlchemy which addresses
issues such as parameter styles, object naming, and even differences in
SQL dialects.
--
Carst
On Tue, 2006-12-19 at 10:28 -0500, Art Protin wrote:
> I am probably being dense here, but ... This seems to be like saying
> "The implementor is free to transfer parameters for .executemany() in
> groups of 17, or not." Why mention it at all?
It's an implementation hint. Take it or leave it.
> D
a case, the above would be the same as .execute(SQL).
I beg to differ. I think it's quite clear from the spec that
cursor.executemany(SQL, []) is a no-op. To actually execute a
parameter-less query with executemany, you'd have to pass an empty
parameter tuple as in cursor.executemany
; ) shouldn't the interface module execute the query zero times, ie, not
> execute the query at all?
Yes, executemany() with an empty sequence is a no-op.
--
Carsten Haese | Phone: (419) 861-3331
Software Engineer| Direct Line: (419) 794
o retrieve opaque types in their binary representation
Downloads and info at http://informixdb.sourceforge.net
Best regards,
Carsten Haese
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Thu, 2006-11-16 at 13:18 -0500, Art Protin wrote:
> Dear folks,
> In earlier messages, I noted that the Specification (v2.0) does
> not adequately express that the "operation" argument is SQL (although
> the coverage of the API in "PYHON in a Nutshell is hardly ambiguous at
> all). Now
On Mon, 2006-11-13 at 11:28 -0500, Art Protin wrote:
> I just looked at Martin's suggestions and I find some theoretical
> problems. I had been left with the impression that the "operation"
> given as an argument to the .execute() method was SQL but on rereading
> the specification (PEP 249) I d
1 - 100 of 131 matches
Mail list logo
