Why are you using such old versions? Why not 3.2.0?
Does the problem occur with KInterbasDB 3.2.0, if it's compiled with 'checked_build=1' in setup.cfg?
The official release of 3.2.0 is compiled with assertions off. If you're not able to compile 3.2.0 with check_build=1 yourself, I can provide you with a binary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use last CVS sources.
In file version.txt - 3.2_20060901
In __init__.py - __version__ = (3, 2, 0, 'final', 0)
and __timestamp__ = '2006.09.01.16.03.22.UTC'
Release date = 2006.08.12
I use old version?
I change only key database_home_dir in section [manual_config]
But I compile Mingw32 v 3.4.5
First compiller command line:
C:\Lang\mingw\bin\gcc.exe -mno-cygwin -mdll -Wall -O3 -Wno-strict-aliasing -mtune=pentium3 -march=pentium3 -DWIN32 -IC:\Lang\Python\24\include -IC:/Lang/Firebird/Firebird_2_0\include -IC:\Lang\Python\24\include -IC:\Lang\Python\24\PC -c _kinterbasdb.c -o build\temp.win32-2.4\Release\_kinterbasdb.o -pedantic -std=c99 -fno-strict-aliasing
Maybe You forget define NDEBUG for gcc:
file setup.py line 1069:
if CHECKED_BUILD:
# Lack of a second tuple element is the distutils conventions for
# "undefine this macro".
allMacroDefs.append(('NDEBUG',))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I change setup.py and compile module with NDEBUG=1
file setup.py line 1069:
if CHECKED_BUILD:
# Lack of a second tuple element is the distutils conventions for
# "undefine this macro".
allMacroDefs.append(('NDEBUG',))
else:
allMacroDefs.append(('NDEBUG', 1))
test.py crach with output:
1
Traceback (most recent call last):
File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 52, in ?
main()
File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 49, in main
work()
File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 42, in work
for row in curs:
TypeError: 'dict' object is not callable
If in BLOB have NULL I catch crash
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I've tried running the full KInterbasDB test suite against:
- 3.2.0
- the current 3.2 branch (which is a bit more recent than is available in CVS, but shouldn't contain any changes relevant to this situation)
- the current 3.3 branch
These tests were run on the Russian version of Windows 2000 Pro SP4 (I don't have Windows XP), with Python 2.5.0, FB 2.0.0 SS, and MinGW 3.4.5 (with CHECKED_BUILD both 0 and 1, and the setup.py fix that you suggested, so that a MinGW CHECKED_BUILD=0 actually disables assertions).
I was not able to reproduce the behavior you're seeing under any of these configurations.
Can you provide me with example client code that triggers the problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All code in test.py:
In functuion init() - create empty database and create table (T3).
In functuion work() - connect, configure blob translations, full table and select.
Problebm show in select (line 41) if in table exists NULL value (line 40)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I've posted a snapshot of KInterbasDB 3.3 in which everything is fixed. I plan to backport only the most conservative of those changes to KInterbasDB 3.2.1. This feature doesn't really work with FB < 2.1, anyway, so having it work in KIDB 3.2.x doesn't deliver much real value.
The automatic encoding and decoding of textual blobs, which you're trying to enable in test.py, cannot work "properly" with any version of Firebird prior to 2.1, because older FB versions don't provide the information necessary for KInterbasDB to automatically determine a blob field's character set, when converting in the input direction. I discussed that in 2005 in this forum post: http://sourceforge.net/forum/message.php?msg_id=3213526
In the posted snapshot of KInterbasDB 3.3, I added a type_conv code 300, which is exactly like 200, except that it also enables automatic encoding/decoding for textual blobs. It will only work *properly* with Firebird 2.1+ (yes, I tested it), but I added the following hack for earlier FB versions:
When type_conv >= 300 is enabled and KInterbasDB is running against a version of FB prior to 2.1, KInterbasDB will assume that it should use the Connection.charset to encode and decode textual blobs. This isn't really safe, but it must be explicitly enabled by using kinterbasdb.init(type_conv=300), and becomes genuinely safe with FB 2.1+.
So, that seems to me like a reasonable compromise. Your original test.py can now achieve its goals as shown in the attached test2.py.
I've now backported the basic elements of the fix (don't die with an assertion) to 3.2 (you will need to use 3.3 to get the new "automatic encoding/decoding for textual input blobs" feature (and that feature can only work reliably with FB 2.1+)).
I'll make a new 3.2 snapshot available soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simple script for reproduction problem
Logged In: YES
user_id=980085
Originator: YES
os: WinXP Home Rus + Sp2
python: 2.4.4
kinterbasdb: 3.2_20060901
firebird: 2.0 b(12810)
Logged In: YES
user_id=414645
Originator: NO
---
kinterbasdb: 3.2_20060901
firebird: 2.0 b(12810)
---
Why are you using such old versions? Why not 3.2.0?
Does the problem occur with KInterbasDB 3.2.0, if it's compiled with 'checked_build=1' in setup.cfg?
The official release of 3.2.0 is compiled with assertions off. If you're not able to compile 3.2.0 with check_build=1 yourself, I can provide you with a binary.
Logged In: YES
user_id=980085
Originator: YES
I use last CVS sources.
In file version.txt - 3.2_20060901
In __init__.py - __version__ = (3, 2, 0, 'final', 0)
and __timestamp__ = '2006.09.01.16.03.22.UTC'
Release date = 2006.08.12
I use old version?
I change only key database_home_dir in section [manual_config]
But I compile Mingw32 v 3.4.5
First compiller command line:
C:\Lang\mingw\bin\gcc.exe -mno-cygwin -mdll -Wall -O3 -Wno-strict-aliasing -mtune=pentium3 -march=pentium3 -DWIN32 -IC:\Lang\Python\24\include -IC:/Lang/Firebird/Firebird_2_0\include -IC:\Lang\Python\24\include -IC:\Lang\Python\24\PC -c _kinterbasdb.c -o build\temp.win32-2.4\Release\_kinterbasdb.o -pedantic -std=c99 -fno-strict-aliasing
Maybe You forget define NDEBUG for gcc:
file setup.py line 1069:
if CHECKED_BUILD:
# Lack of a second tuple element is the distutils conventions for
# "undefine this macro".
allMacroDefs.append(('NDEBUG',))
Logged In: YES
user_id=980085
Originator: YES
I change setup.py and compile module with NDEBUG=1
file setup.py line 1069:
if CHECKED_BUILD:
# Lack of a second tuple element is the distutils conventions for
# "undefine this macro".
allMacroDefs.append(('NDEBUG',))
else:
allMacroDefs.append(('NDEBUG', 1))
test.py crach with output:
1
Traceback (most recent call last):
File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 52, in ?
main()
File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 49, in main
work()
File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 42, in work
for row in curs:
TypeError: 'dict' object is not callable
If in BLOB have NULL I catch crash
Logged In: YES
user_id=414645
Originator: NO
Ok, thanks for the report. I'll investigate this tomorrow evening.
Logged In: YES
user_id=414645
Originator: NO
Well, I've tried running the full KInterbasDB test suite against:
- 3.2.0
- the current 3.2 branch (which is a bit more recent than is available in CVS, but shouldn't contain any changes relevant to this situation)
- the current 3.3 branch
These tests were run on the Russian version of Windows 2000 Pro SP4 (I don't have Windows XP), with Python 2.5.0, FB 2.0.0 SS, and MinGW 3.4.5 (with CHECKED_BUILD both 0 and 1, and the setup.py fix that you suggested, so that a MinGW CHECKED_BUILD=0 actually disables assertions).
I was not able to reproduce the behavior you're seeing under any of these configurations.
Can you provide me with example client code that triggers the problem?
Logged In: YES
user_id=980085
Originator: YES
All code in test.py:
In functuion init() - create empty database and create table (T3).
In functuion work() - connect, configure blob translations, full table and select.
Problebm show in select (line 41) if in table exists NULL value (line 40)
Logged In: YES
user_id=414645
Originator: NO
Oops, I didn't notice the attachment (duh...). I'll experiment with it tomorrow.
With new 3.3 snapshot, original script can be simpler
Logged In: YES
user_id=414645
Originator: NO
Ok, I've posted a snapshot of KInterbasDB 3.3 in which everything is fixed. I plan to backport only the most conservative of those changes to KInterbasDB 3.2.1. This feature doesn't really work with FB < 2.1, anyway, so having it work in KIDB 3.2.x doesn't deliver much real value.
The automatic encoding and decoding of textual blobs, which you're trying to enable in test.py, cannot work "properly" with any version of Firebird prior to 2.1, because older FB versions don't provide the information necessary for KInterbasDB to automatically determine a blob field's character set, when converting in the input direction. I discussed that in 2005 in this forum post:
http://sourceforge.net/forum/message.php?msg_id=3213526
In the posted snapshot of KInterbasDB 3.3, I added a type_conv code 300, which is exactly like 200, except that it also enables automatic encoding/decoding for textual blobs. It will only work *properly* with Firebird 2.1+ (yes, I tested it), but I added the following hack for earlier FB versions:
When type_conv >= 300 is enabled and KInterbasDB is running against a version of FB prior to 2.1, KInterbasDB will assume that it should use the Connection.charset to encode and decode textual blobs. This isn't really safe, but it must be explicitly enabled by using kinterbasdb.init(type_conv=300), and becomes genuinely safe with FB 2.1+.
So, that seems to me like a reasonable compromise. Your original test.py can now achieve its goals as shown in the attached test2.py.
Here's the new KIDB 3.3 snapshot:
http://kinterbasdb.sourceforge.net/snapshots/3.3/kinterbasdb-3.3_pre_20070210.src.tar.bz2
Thank you for the bug report!
File Added: test2.py
Logged In: YES
user_id=414645
Originator: NO
This is to remind me that, as of 2007-04-04, I haven't yet backported this fix to 3.2.
Logged In: YES
user_id=414645
Originator: NO
I've now backported the basic elements of the fix (don't die with an assertion) to 3.2 (you will need to use 3.3 to get the new "automatic encoding/decoding for textual input blobs" feature (and that feature can only work reliably with FB 2.1+)).
I'll make a new 3.2 snapshot available soon.