TDBC

dgp informs me that tcl_findLibrary should be considered obsolete. 
The current thinking on how to structure a module is that both the 
C code for the module and any Tcl scripts required should be loaded 
from pkgIndex.tcl, and the 'tcl_findLibrary' hack should never be 
needed. (It appears that there are some order-of-initialization 
issues to resolve with the recommended approach, but these can be 
tackled if necessary by adding commands in the C code to be called 
at the appropriate point in the Tcl code, so that the sequence will 
be load DLL - source Tcl library - Tcl library calls initialisation 
in DLL in whatever order is needed.

<hr><i>kennykb added on 2010-09-03 18:10:19:</i><br>
It's got rid of. pkgIndex.tcl now sources the Tcl script and then loads the library. There are a few subtleties that are attended to.

compilation fails with the following message: 
 
Building package 'tdbc' 
gcc -DPACKAGE_NAME=\"tdbc\" -DPACKAGE_TARNAME=\"tdbc\" -DPACKAGE_VERSION=\"1.0b1\" -DPACKAGE_STRING=\"tdbc\ 1.0b1\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1   -I"/home/emiliano/src/tcl/generic"    -pipe -pthread -O2 -Wall -fPIC -c `echo /home/emiliano/src/tcl/pkgs/tdbc/generic/tdbc.c` -o tdbc.o 
gcc -DPACKAGE_NAME=\"tdbc\" -DPACKAGE_TARNAME=\"tdbc\" -DPACKAGE_VERSION=\"1.0b1\" -DPACKAGE_STRING=\"tdbc\ 1.0b1\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1   -I"/home/emiliano/src/tcl/generic"    -pipe -pthread -O2 -Wall -fPIC -c `echo /home/emiliano/src/tcl/pkgs/tdbc/generic/tdbcStubInit.c` -o tdbcStubInit.o 
gcc -DPACKAGE_NAME=\"tdbc\" -DPACKAGE_TARNAME=\"tdbc\" -DPACKAGE_VERSION=\"1.0b1\" -DPACKAGE_STRING=\"tdbc\ 1.0b1\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1   -I"/home/emiliano/src/tcl/generic"    -pipe -pthread -O2 -Wall -fPIC -c `echo /home/emiliano/src/tcl/pkgs/tdbc/generic/tdbcTokenize.c` -o tdbcTokenize.o 
/home/emiliano/src/tcl/pkgs/tdbc/generic/tdbcTokenize.c: In function 'Tdbc_TokenizeSql': 
/home/emiliano/src/tcl/pkgs/tdbc/generic/tdbcTokenize.c:138: warning: array subscript has type 'char' 
/home/emiliano/src/tcl/pkgs/tdbc/generic/tdbcTokenize.c:139: warning: array subscript has type 'char' 
/home/emiliano/src/tcl/pkgs/tdbc/generic/tdbcTokenize.c:146: warning: array subscript has type 'char' 
rm -f libtdbc1.0b1.so 
gcc -shared -fPIC -o libtdbc1.0b1.so tdbc.o tdbcStubInit.o tdbcTokenize.o  -L/home/emiliano/src/tcl/unix -ltclstub8.6 
ld: tdbc.o: relocation R_X86_64_PC32 against `tdbcStubs' can not be used when making a shared object; recompile with -fPIC 
ld: final link failed: Bad value 
 
this patch solves the problem 
--- ./pkgs/tdbc/generic/tdbcStubInit.c.orig     2008-12-23 02:04:46.000000000 -0200 
+++ ./pkgs/tdbc/generic/tdbcStubInit.c  2008-12-23 02:08:14.000000000 -0200 
@@ -17,7 +17,7 @@ 
  
 /* !BEGIN!: Do not edit below this line. */ 
  
-TdbcStubs tdbcStubs = { 
+MODULE_SCOPE TdbcStubs tdbcStubs = { 
     TCL_STUB_MAGIC, 
     TDBC_STUBS_EPOCH, 
     TDBC_STUBS_REVISION,

<hr><i>kennykb added on 2008-12-30 17:38:05:</i><br>
Fixed in [651d34d627]

Currently, the error code returned from TDBC drivers looks like: 
<pre> 
TDBC <driver> <sqlstate> <detail> 
</pre> 
It should rather be: 
<pre> 
TDBC <category> <sqlstate> <driver> <detail> 
</pre> 
where <category> is a human-readable description of the error category obtained from the first two characters of sqlstate. 
<p>This change would make it possible for a 'try' call to catch a particular sort of SQL error, for instance 'data exception': 
<pre> 
TDBC DATAEXCEPTION ... 
</pre> 
or more specifically 'division by zero': 
<pre> 
TDBC DATAEXCEPTION 22012 ... 
</pre>

When $(SCRIPT_INSTALL_DIR) has spaces in the name, the install-libraries target fails on the $(CPY) operation. 
 
 
Index: makefile.vc 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/win/makefile.vc,v 
retrieving revision 1.3 
diff -c -r1.3 makefile.vc 
*** makefile.vc	22 Dec 2008 00:42:03 -0000	1.3 
--- makefile.vc	7 Jan 2009 20:59:23 -0000 
*************** 
*** 466,472 **** 
  	@echo Installing libraries to '$(SCRIPT_INSTALL_DIR)' 
  	@if exist $(LIBDIR) $(CPY) $(LIBDIR)\*.tcl "$(SCRIPT_INSTALL_DIR)" 
  	@echo Installing package index in '$(SCRIPT_INSTALL_DIR)' 
! 	@$(CPY) $(OUT_DIR)\pkgIndex.tcl $(SCRIPT_INSTALL_DIR) 
   
  install-docs: 
  	@echo Installing documentation files to '$(DOC_INSTALL_DIR)' 
--- 466,472 ---- 
  	@echo Installing libraries to '$(SCRIPT_INSTALL_DIR)' 
  	@if exist $(LIBDIR) $(CPY) $(LIBDIR)\*.tcl "$(SCRIPT_INSTALL_DIR)" 
  	@echo Installing package index in '$(SCRIPT_INSTALL_DIR)' 
! 	@$(CPY) $(OUT_DIR)\pkgIndex.tcl "$(SCRIPT_INSTALL_DIR)" 
   
  install-docs: 
  	@echo Installing documentation files to '$(DOC_INSTALL_DIR)'

<hr><i>kbk added on 2009-01-08 03:35:43:</i><br>
Thanks for the patch, Davy. I've merged it upstream.  Kevin

Hi! 
 
Currently tdbc shared library is built without -fPIC option, which may 
cause build problems on architectures other than x86. You can see build 
failures on x86_64 
(http://experimental.debian.net/fetch.php?&pkg=tcl8.6&ver=8.6.0%7Eb1-1&arch 
=amd64&stamp=1230511061&file=log&as=raw) and HP PA-RISC 
(http://experimental.debian.net/fetch.php?&pkg=tcl8.6&ver=8.6.0%7Eb1-1&arch 
=hppa&stamp=1230521525&file=log&as=raw) architectures. 
 
To fix this bug it should be sufficient to add $(SHLIB_CFLAGS) to COMPILE 
definition: 
<pre> 
--- tcl8.6-8.6.0~b1.orig/pkgs/tdbc1.0b1/Makefile.in 
+++ tcl8.6-8.6.0~b1/pkgs/tdbc1.0b1/Makefile.in 
@@ -167,7 +167,7 @@ 
LIBS = @PKG_LIBS@ @LIBS@ 
AR = @AR@ 
CFLAGS = @CFLAGS@ 
-COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
$(AM_CFLAGS) $(CFLAGS) 
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) 
$(AM_CFLAGS) $(CFLAGS) $(SHLIB_CFLAGS) 
 
#======================================================================== 
# Start of user-definable TARGETS section 
</pre>

<hr><i>kbk added on 2009-02-06 17:44:08:</i><br>
Teo verifies that 1.0b4 in the Tcl HEAD fixes the problem.

 
When installed, tdbc 1.0b1 installs a 
pkgIndex.tcl file with these contents: 
 
if {[catch {package require Tcl }]} return 
package ifneeded tdbc 1.0b1 \ 
    [list load [file join $dir libtdbc1.0b1.so] tdbc] 
 
And when a 8.4 or earlier interp [source]s 
that, it barfs on "1.0b1". 
 
Something didn't get substituted right in 
the screening line.

<hr><i>dgp added on 2009-01-15 21:34:55:</i><br>
 
The Makefile sticks in the value 
of $(TCL_VERSION_REQ) at the critical 
spot, but that appears to be undefined.

<hr><i>kbk added on 2009-02-15 02:01:03:</i><br>
pkgIndex.tcl changed per dgp's suggestions and released in 1.0b8. 
1.0b8 has been merged to the Tcl HEAD.

Man pages are needed for tdbc::mapSqlState and Tdbc_MapSqlState

--- README.orig Tue Feb 10 07:01:33 2009 
+++ README      Tue Feb 10 07:05:34 2009 
@@ -4,3 +4,3 @@ 
     (TDBC). TDBC is available from a Fossil version control repository 
-       at http://tdbc.tcl.tk/ 
+       at http://tdbc.tcl.tk/ . 
  
@@ -15,3 +15,3 @@ 
 The drivers are available from http://tdbc.tcl.tk along with the 
-source code of this module A bug database and Wiki are available  
+source code of this module. A bug database and Wiki are available  
 at the same location. 
@@ -28,3 +28,3 @@ 
 commands; files with an extension '.3' are for C library functions. The 
-file, 'doc/tdbc.n' gives an overview, listing the classes and functions  
+file, 'doc/tdbc.n' gives an overview, listing the classes and functions. 
  
@@ -91,3 +91,3 @@ 
 The Tcl community is too large for us to provide much individual support 
-for users.  If you need help we suggest that you post questions to 
+for users.  If you need help, we suggest that you post questions to 
 comp.lang.tcl.  We read the newsgroup and will attempt to answer esoteric

<hr><i>kbk added on 2009-02-15 01:52:59:</i><br>
Fixes applied to the head, will be included in 1.0b9 or 1.0.0, whichever comes first.

<hr><i>kbk added on 2009-02-16 21:17:10:</i><br>
Fixes merged to the Tcl HEAD from 1.0b9

This script fails as shown: 
 
package require tdbc::mysql 
set dbx [tdbc::mysql::connection new -user tester -password tester -db test] 
 
 
foreach sql { 
    "DROP TABLE IF EXISTS competition_types" 
    "CREATE TABLE competition_types (cty_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, cty_name VARCHAR(16) NOT NULL, cty_nplayers TINYINT NOT NULL)" 
    "INSERT INTO competition_types (cty_name, cty_nplayers) VALUES ('individual', 1), ('pairs', 2), ('teams', 4)" 
    "DESCRIBE competition_types" 
    "SELECT * FROM competition_types" 
} { 
    puts stdout "Executing $sql" 
    $dbx foreach row $sql { 
	puts stdout $row 
    } 
    puts stdout "" 
} 
 
set sql "SELECT * FROM competition_types WHERE cty_name=:name" 
 
puts stdout "Using database foreach method" 
foreach name {individual pairs teams} { 
    $dbx foreach row $sql [dict create name $name] { 
	puts stdout $row 
	flush stdout 
    } 
} 
puts stdout "" 
 
set stmt [$dbx prepare $sql] 
 
puts stdout "Using statement foreach method" 
foreach name {individual pairs teams} { 
    $stmt foreach row [dict create name $name] { 
	puts stdout $row 
	flush stdout 
    } 
} 
puts stdout "" 
 
puts stdout "Using statement allrows method" 
foreach name {individual pairs teams} { 
    puts stdout [$stmt allrows [dict create name $name]] 
    flush stdout 
} 
 
Output: 
 
Executing DROP TABLE IF EXISTS competition_types 
 
Executing CREATE TABLE competition_types (cty_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, cty_name VARCHAR(16) NOT NULL, cty_nplayers TINYINT NOT NULL) 
 
Executing INSERT INTO competition_types (cty_name, cty_nplayers) VALUES ('individual', 1), ('pairs', 2), ('teams', 4) 
 
Executing DESCRIBE competition_types 
Field cty_id Type int(11) Null NO Key PRI Extra auto_increment 
Field cty_name Type varchar(16) Null NO Key {} Extra {} 
Field cty_nplayers Type tinyint(4) Null NO Key {} Extra {} 
 
Executing SELECT * FROM competition_types 
cty_id 1 cty_name individual cty_nplayers 1 
cty_id 2 cty_name pairs cty_nplayers 2 
cty_id 3 cty_name teams cty_nplayers 4 
 
Using database foreach method 
cty_id 1 cty_name individual cty_nplayers 1 
cty_id 2 cty_name pairs cty_nplayers 2 
cty_id 3 cty_name teams cty_nplayers 4 
 
Using statement foreach method 
cty_id 1 cty_name individual cty_nplayers 1 
cty_id 2 cty_name pairs cty_nplayers 2 
cty_id 3 cty_name teams cty_nplayers 4 
 
Using statement allrows method 
{cty_id 1 cty_name individual cty_nplayers 1} 
{cty_id 2 cty_name pairs cty_nplayers 2} 
Segmentation fault 
 
The fault happens consistently at this point, but small changes to the script can cause the fault to happen on the second statement allrows call. (I.e. the "cty_id 2" line is not output.) 
 
Setup: 
 
Tcl 8.6b1.1 
ActiveTcl 8.6.0.0.289006 
tdbc 1.0b7 
tdbc::mysql 1.0b7 
 
Ubuntu 8.04 
 
MySQL 5.0.51a-3ubuntu5.4

<hr><i>kbk added on 2009-04-16 23:03:16:</i><br>
Fixed in commit [f09e74d5c6]

The syntax of the foreach method of a statement object is documented to be 
 
(according to the manpage:) 
 
    $stmt foreach ?-as lists|dicts?  ?-columnsvariable name? ?--? dict varName script 
 
(according to TIP#308) 
 
    statement foreach ?-as lists|dicts? ?-columnsvariable varName? ?--? ?dictionary? varName script 
 
i.e., it's dictionary before varName. At least in the tdbc::sqlite3 driver however, it's implemented the other way around, as can be seen for example in the following test: 
 
<verbatim> 
test tdbcsqlite3-9.33 {stmt foreach / parameters in a dictionary} {*}{ 
    -setup { 
        set stmt [::db prepare {
            SELECT idnum, name FROM people WHERE name LIKE :thePattern
        }] 
        $stmt paramtype thePattern varchar 40 
    } 
    -body { 
        set result {} 
        $stmt foreach row {thePattern b%} { 
            lappend result $row 
        } 
        set result 
    } 
    -cleanup { 
        $stmt close 
    } 
    -result {{idnum 4 name barney} {idnum 5 name betty} {idnum 6 name bam-bam}} 
} 
</verbatim> 
 
(Typing this down, I also notice that the manpage is missing ?'s around the dict argument, but that's a separate issue.)

The script below demonstrates that if a DROP TABLE statement fails, then an error is thrown without any text. 
 
I suspect that the problem may apply to many if not all data definition statements, since executing the same CREATE TABLE command twice in succession has the same effect. 
 
I further suspect that this problem lies in the tdbc::mysql driver rather than the tdbc core, since if you execute the same CREATE TABLE command twice in succession on an sqlite3 connection the error "table FOO already exists" is thrown. 
 
package require tdbc::mysql; 
 
set db [tdbc::mysql::connection new -db test -user tester -password tester]; 
 
$db allrows { 
    CREATE TABLE parent ( 
	parent_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY 
    ) ENGINE=InnoDb}; 
$db allrows { 
    CREATE TABLE child ( 
	child_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, 
	child_parent INTEGER NOT NULL, 
	FOREIGN KEY (child_parent) REFERENCES parent (parent_id) 
    ) ENGINE=InnoDb}; 
if {[catch {
    $db allrows {DROP TABLE parent}
}]} { 
    puts stdout "errorCode: $errorCode" 
}; 
$db close

<hr><i>kbk added on 2009-04-17 00:12:50:</i><br>
I'm not able to reproduce the behaviour that you describe. 
 
Modifying your script to cause 'catch' to capture the error message: 
 
<verbatim> 
package require tdbc::mysql 
 
set db [tdbc::mysql::connection new -socket $env(TEST_SOCKET) \
	    -db tdbc_test -password $env(TEST_PASSWD)] 
 
$db allrows {DROP TABLE IF EXISTS child} 
$db allrows {DROP TABLE IF EXISTS parent} 
$db allrows { 
    CREATE TABLE parent ( 
	parent_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY 
    ) ENGINE=InnoDb} 
$db allrows { 
    CREATE TABLE child ( 
	child_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, 
	child_parent INTEGER NOT NULL, 
	FOREIGN KEY (child_parent) REFERENCES parent (parent_id) 
    ) ENGINE=InnoDb} 
puts [list [catch {
    puts "Deleting parent"
    $db allrows {DROP TABLE parent}
} result] $result $::errorCode] 
 
$db close 
</verbatim> 
 
I get the result: 
 
<verbatim> 
Deleting parent 
1 {Cannot delete or update a parent row: a foreign key constraint fails} {TDBC CONSTRAINT_VIOLATION 23000 MYSQL 1217} 
</verbatim> 
 
which appears to be an entirely reasonable explanation of what went wrong with deleting the table. 
 
I don't know whether I inadvertently fixed the problem while doing something else, or whether your original script had an issue.

<hr><i>kbk added on 2009-04-18 02:42:22:</i><br>
The user retested in 1.0b10 and is now unable to reproduce the problem. 
 
I didn't do anything intentionally to fix it, but I wasn't able to 
reproduce it, either.

The error from 
 
    tdbc::<driver>::connection foo ... 
 
suggests, and experiment confirms that 
 
    tdbc::<driver>::connection new ... 
 
is a valid command. 
 
It's not documented.

<hr><i>kbk added on 2009-04-06 02:17:02:</i><br>
all of the drivers, not just tdbc::mysql, need this change.

A user reports in email that tdbc::mysql documentation has an inconsistency 
between 'starttransaction' and 'begintransaction' object commands. Need to 
correct documentation throughout and edit TIP 308 as necessary.

TIP 308 has the 'execute' method on tdbc statements, and the related  
methods, throw an error if the statement contains a reference to a  
variable ':x', but the Tcl variable 'x' is an array. This turns out 
to be an awkward check to make (there's no way to do it cheaply from 
C, and it greatly complicates the code in a Tcl driver). Need to 
make an editorial change to 308 to use NULL in that case (the plain 
variable 'x' arguably does not exist) and change the mysql and 
odbc drivers accordingly. (The same applies if 'x' has a read trace 
that throws an error.)

There is no man page for Tdbc_TokenizeSql; there needs to be one.

Julian Noble reports, on http://wiki.tcl.tk/: 
 
I'm using the precompiled windows tdbc1.0b9 and tdbcodbc1.0b9 - and I'm getting a strange error with some MS Access MEMO fields. A nul character (\0) is appearing at exactly character position 255 within a field value in a '$resultset foreach row ..' loop. (resultset returned from a query ie: 
<verbatim> 
[db prepare "select * from $queryname"] execute] 
</verbatim> 
 ) 
 
I tried producing a simplified version of my program in order to submit a bug report - but couldn't reproduce it in the simple program :( It's got me beat as to where this nul is coming from. 
 
Just flagging it here for now in case someone has some debugging ideas etc..

<hr><i>kbk added on 2009-05-04 04:59:41:</i><br>
Suspect an off-by-one error in the buffer reallocation code near 
'convertString:' in tdbcodbc/generic/tdbcodbc.c(GetCell)

<hr><i>kbk added on 2009-05-30 02:14:16:</i><br>
Alan Grunwald reported the same problem, and it should finally be fixed. 
 
The ODBC documentation doesn't entirely tell the truth about null bytes at 
the end of a partial buffer.  A SQL_C_CHAR buffer has a null byte; a 
SQL_C_WCHAR buffer has a null WCHAR, and a SQL_C_BINARY buffer has no terminator. 
The code now adjusts byte counts with this in mind.

    method statementCreate {name instance sqlCode} { 
	my variable statementClass 
	return [$statementClass create $name $instance $sqlcode] 
    } 
 
results in error: can't read "sqlcode": no such variable, during a call such as: $cmd prepare $sql

<hr><i>kbk added on 2009-07-03 05:56:18:</i><br>
Fixed in 1.0b12

A dll for tdbcodbc used to be included in the windows binaries available at: 
https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160 
 
..but the latest file tdbc1.0b11-win32.zip doesn't include tdbcodbc 
 
Is this intentional?

<hr><i>kbk added on 2009-07-03 06:00:53:</i><br>
If it was missing, it was unintentional. 
 
There certainly is one in the 1.0b12 zip.

Testing against an MS SQLServer using the following script: 
 
package require tdbc::odbc 
set connstr  "Driver={SQL Native Client};Server=127.0.0.1; Database=somedb;Uid=someone;Pwd=somepass;" 
tdbc::odbc::connection create db $connstr 
set allcolinfo [db columns items] 
 
The script raises the error: 
can't use non-numeric string as operand of "!" 
 
  
The specific line within the 'columns' method is: 
dict set row nullable \ 
			[expr {!![dict get $row is_nullable]}] 
 
By placing a puts statement above this line, I found that [dict get $row is_nullable] returns "NO "   ie - there is a trailing space which causes it to be invalid in the expr.

<hr><i>kbk added on 2009-07-03 06:24:25:</i><br>
Fixed in 1.0b12

While developing a script to download and build tcl/tk, I noticed that after I compiled tcl, re-./configured with a new --prefix, that tdbc would not build again and that it would make install into the previous --prefix. 
 
I believe it happens to itcl as well, as its also a package and the logic in ./configure tests for the existence of a Makefile to decide whether to rebuild the two extensions.

<hr><i>kbk added on 2009-06-26 01:57:12:</i><br>
This is a Tcl build problem, not a TDBC one... referring it to the Tcl project

<verbatim> 
 
tdbc::odbc crashes tclsh when retrieving DECIMAL data from Oracle.  
MS Sql Server works properly with DECIMALs.  
 
 
Oracle databases: 10.02.0040 (both win and oracle are 64-bit), 10.02.0020 (SunOS 5.9) and 09.02.0010 (SunOS 5.9) 
 
Table myTable:  
decimalNumber DECIMAL(10)       freeText VARCHAR2(10)  
123456                          word1  
654321                          word2  
 
 
Retrieving VARCHAR2 works fine 
~: set db [::tdbc::odbc::connection new "DSN=myDatabase; UID=user; PWD=pass;"] 
~: $db allrows "SELECT COUNT(freeText) FROM myTable" 
~: {COUNT(FREETEXT) 2.0} 
~: $db allrows "SELECT freeText FROM myTable" 
~: {FREETEXT word1} {FREETEXT word2} 
 
Retrieving DECIMAL crashes tclsh 
~: $db allrows "SELECT COUNT(decimalNumber) FROM myTable" 
~: {COUNT(DECIMALNUMBER) 2.0} 
~: $db allrows "SELECT decimalNumber FROM myTable" 
alloc: invalid block: 0012F31C: 40 0 
abnormal program termination 
 
 
</verbatim>

<hr /><i>anonymous added on 2010-12-13 15:13:45:</i><br />
I guess the crash is provoked by SQLGetData() when using it with SQL_C_SBIGINT or SQL_C_UBIGINT. Both types are not supported by the Oracle ODBC driver. A workaround may be to treat theses "big" integers as strings.

<hr /><i>kennykb added on 2011-02-21 06:36:25:</i><br />
The crash is fixed (in commit [145e893bf82]). The underlying problem - suspected but not proven to be lack of bigint support in the Oracle ODBC driver - is still outstanding. Email sent to the original submitter: 
<verbatim> 
I'm sorry that I've been so long at getting back to this bug. 
It's surely catastrophic, and the only excuse I have is that 
I misread the headline totally, and misunderstood it to be 
against the (unfinished and unsupported) tdbc::oracle driver. 
Mea culpa. 
 
I think that your analysis about SQL_C_SBIGINT may indeed be 
correct, since I've found where it will crash if SQLGetData 
fails.  I'll surely fix the crash so that it returns the 
correct error code (which I strongly suspect is 
either 22003 Numeric value out of range or 
07006 Restricted data type attribute violation).  But that, 
of course, won't fix the underlying problem. 
 
I think I have an idea how to go about fixing it, though. 
Could I get you to open a tdbc::odbc connection to an Oracle 
instance and mail me back the result of: 
 
    set typesStmt [::tdbc::odbc::typesStatement new $connection] 
    $typesStmt foreach row {puts $row} 
    $typesStmt close 
 
? That should enumerate the data types that Oracle is prepared 
to cope with, and if I'm right, -5 (bigint) isn't among them. 
If that's the case, I can do a similar hack to what I do to 
avoid handing wvarchar to database that can't accept it.  
</verbatim>

<hr /><i>kennykb added on 2011-02-22 02:26:40:</i><br />
Fix committed in [46f95ec3128], please test.

The problem described in [10f4a9c15a4] appears to have regressed. I rolled forward to today's commit [cba4d6c4a0], and I don't see the patch applied 
in configure.in.

<hr><i>anonymous added on 2009-07-22 02:32:43:</i><br>
For what it's worth, here are the current diffs that make the code buildable on mingw+msys.  I added a couple more messages to the configurator, the better to track what's going on. 
 
<verbatim> 
Index: tdbcpostgres/Makefile.in 
=================================================================== 
"d:\Fossil\fossil.exe" diff d:/home/200002852/tdbc-slavek/tdbcpostgres/Makefile.in 
--- tdbcpostgres/Makefile.in 
+++ tdbcpostgres/Makefile.in 
@@ -132,11 +132,11 @@ 
 TCLLIBPATH	= $(top_builddir) 
 TCLSH_ENV	= TCL_LIBRARY=`@CYGPATH@ $(TCL_SRC_DIR)/library` 
 PKG_ENV		= @LD_LIBRARY_PATH_VAR@="$(EXTRA_PATH):$(@LD_LIBRARY_PATH_VAR@)" \ 
 		  PATH="$(EXTRA_PATH):$(PATH)" \ 
 		  TCLLIBPATH="$(TCLLIBPATH)" \ 
-                  TDBCMYSQL_LIBRARY=`@CYGPATH@ $(srcdir)/library` 
+                  TDBCPOSTGRES_LIBRARY=`@CYGPATH@ $(srcdir)/library` 
  
 TCLSH_PROG	= @TCLSH_PROG@ 
 TCLSH   	= $(PKG_ENV) $(TCLSH_ENV) $(TCLSH_PROG) 
  
 #WISH_ENV	= TK_LIBRARY=`@CYGPATH@ $(TK_SRC_DIR)/library` 
 
Index: tdbcpostgres/configure.in 
=================================================================== 
"d:\Fossil\fossil.exe" diff d:/home/200002852/tdbc-slavek/tdbcpostgres/configure.in 
--- tdbcpostgres/configure.in 
+++ tdbcpostgres/configure.in 
@@ -196,30 +196,35 @@ 
  
 #---------------------------------------------------------------------- 
 # Get Postgre libpq include files, and set POSTGRESS_INCLUDE_SPEC accordingly 
 #---------------------------------------------------------------------- 
  
+AC_MSG_CHECKING([for PostgreSQL include directory]) 
+POSTGRES_COMMAND="\"${PG_CONFIG}\" --includedir" 
+POSTGRES_INCLUDE_DIR=`eval ${POSTGRES_COMMAND}` 
+AC_MSG_RESULT(${POSTGRES_INCLUDE_DIR}) 
 TDBCPOSTGRES_SAVED_CPPFLAGS="${CPPFLAGS}" 
-POSTGRES_INCLUDE_SPEC="-I`${PG_CONFIG} --includedir`" 
- 
+POSTGRES_INCLUDE_SPEC="-I${POSTGRES_INCLUDE_DIR}" 
 CPPFLAGS="${CPPFLAGS} ${POSTGRES_INCLUDE_SPEC}" 
 AC_CHECK_HEADERS([libpq-fe.h], , AC_MSG_ERROR("cannot find a working libpq-fe.h")) 
- 
 CPPFLAGS="${TDBCPOSTGRES_SAVED_CPPLFAGS}" 
 TEA_ADD_INCLUDES([${POSTGRES_INCLUDE_SPEC}]) 
  
 #---------------------------------------------------------------------- 
 # Locate the libpq library 
 #---------------------------------------------------------------------- 
  
  
-POSTGRES_LIB_SPEC="-L`${PG_CONFIG} --libdir`" 
- 
+AC_MSG_CHECKING([for PostgreSQL library directory]) 
+POSTGRES_COMMAND="\"${PG_CONFIG}\" --libdir" 
+POSTGRES_LIB_DIR=`eval ${POSTGRES_COMMAND}` 
+AC_MSG_RESULT(${POSTGRES_LIB_DIR}) 
+POSTGRES_LIB_SPEC="-L${POSTGRES_LIB_DIR}" 
 TDBCPOSTGRES_SAVED_LDFLAGS="${LDFLAGS}" 
- 
+LDFLAGS="${LDFLAGS} ${POSTGRES_LIB_SPEC}" 
 AC_CHECK_LIB(pq, PQconnectdb, [
-	POSTGRES_LIB_SPEC="${MYSQL_LIB_SPEC} -lpq"
+	POSTGRES_LIB_SPEC="${POSTGRES_LIB_SPEC} -lpq"
     ],  [
             AC_MSG_ERROR("cannot find a working libpq library")
 	    ]) 
  
 LDFLAGS="${TDBCPOSTGRES_SAVED_LDFLAGS}" 
 
Index: tdbcpostgres/tests/current.test 
=================================================================== 
"d:\Fossil\fossil.exe" diff d:/home/200002852/tdbc-slavek/tdbcpostgres/tests/current.test 
--- tdbcpostgres/tests/current.test 
+++ tdbcpostgres/tests/current.test 
@@ -24,11 +24,11 @@ 
 } 
 if {[info exists env(TEST_USER)]} { 
     lappend connFlags -user $env(TEST_USER) 
 } 
 if {[info exists env(TEST_PASSWD)]} { 
-    lappend connFlags -passwd $env(TEST_PASSWD) 
+    lappend connFlags -password $env(TEST_PASSWD) 
 } 
 if {[info exists env(TEST_DB)]} { 
     lappend connFlags -db $env(TEST_DB) 
 } else { 
     lappend connFlags -db tdbc_test 
 
</verbatim>

I tried the tdbcpostgres configurator on a mingw+msys configuration, 
with a default Windows binary distribution of Postgres 8.4.   
 
(1) I found that 'configure' didn't match 'configure.in', so I tried 
    rerunning 'autoconf'.  That would have fixed it except that: 
 
(2) For some reason, 'autom4te.cache' is in the repository. It shouldn't 
    be, and it contained incorrect cached information from 'autoconf'. 
 
(3) Once that was removed, and autoconf-2.59 ran, I ran into trouble 
when 'configure' got to the pg_config material, owing to the spaces in 
file names.  The following patch appeared to fix it: 
 
<verbatim> 
$ /d/Fossil/fossil diff tdbcpostgres/configure.in 
--- tdbcpostgres/configure.in 
+++ tdbcpostgres/configure.in 
@@ -1,6 +1,6 @@ 
-n#!/bin/bash -norc 
+#!/bin/bash -norc 
 dnl    This file is an input file used by the GNU "autoconf" program to 
 dnl    generate the file "configure", which is run during Tcl installation 
 dnl    to configure the system for the local environment. 
 # 
 # RCS: @(#) $Id: configure.in,v 1.47 2007/02/09 19:06:47 hobbs Exp $ 
@@ -196,13 +196,14 @@ 
  
 #---------------------------------------------------------------------- 
 # Get Postgre libpq include files, and set POSTGRESS_INCLUDE_SPEC accordingly 
 #---------------------------------------------------------------------- 
  
+POSTGRES_COMMAND="\"${PG_CONFIG}\" --includedir" 
+POSTGRES_INCLUDE_DIR=`echo ${POSTGRES_COMMAND} | sh` 
 TDBCPOSTGRES_SAVED_CPPFLAGS="${CPPFLAGS}" 
-POSTGRES_INCLUDE_SPEC="-I`${PG_CONFIG} --includedir`" 
- 
+POSTGRES_INCLUDE_SPEC="-I${POSTGRES_INCLUDE_DIR}" 
 CPPFLAGS="${CPPFLAGS} ${POSTGRES_INCLUDE_SPEC}" 
 AC_CHECK_HEADERS([libpq-fe.h], , AC_MSG_ERROR("cannot find a working libpq-fe.h")) 
  
 CPPFLAGS="${TDBCPOSTGRES_SAVED_CPPLFAGS}" 
 TEA_ADD_INCLUDES([${POSTGRES_INCLUDE_SPEC}]) 
@@ -210,16 +211,17 @@ 
 #---------------------------------------------------------------------- 
 # Locate the libpq library 
 #---------------------------------------------------------------------- 
  
  
-POSTGRES_LIB_SPEC="-L`${PG_CONFIG} --libdir`" 
- 
+POSTGRES_COMMAND="\"${PG_CONFIG}\" --libdir" 
+POSTGRES_LIB_DIR=`echo ${POSTGRES_COMMAND} | sh` 
+POSTGRES_LIB_SPEC="-L${POSTGRES_LIB_DIR}" 
 TDBCPOSTGRES_SAVED_LDFLAGS="${LDFLAGS}" 
- 
+LDFLAGS="${LDFLAGS} ${POSTGRES_LIB_SPEC}" 
 AC_CHECK_LIB(pq, PQconnectdb, [
-       POSTGRES_LIB_SPEC="${MYSQL_LIB_SPEC} -lpq"
+       POSTGRES_LIB_SPEC="${POSTGRES_LIB_SPEC} -lpq"
     ],  [
             AC_MSG_ERROR("cannot find a working libpq library")
            ]) 
  
 LDFLAGS="${TDBCPOSTGRES_SAVED_LDFLAGS}" 
 
 
</verbatim>

<hr><i>slawek added on 2009-07-15 17:25:22:</i><br>
Done, thanks very much.

Trying to do 'make shell' after building tdbcpostgres runs a shell, but fails to set things up to load the tdbcpostgres10b11.dll from the build directory. The problem turns out to be that it's using an environment variable name with 'MYSQL' 
in it.  The following patch is suggested to fix it. 
 
<verbatim> 
--- tdbcpostgres/Makefile.in 
+++ tdbcpostgres/Makefile.in 
@@ -132,11 +132,11 @@ 
 TCLLIBPATH     = $(top_builddir) 
 TCLSH_ENV      = TCL_LIBRARY=`@CYGPATH@ $(TCL_SRC_DIR)/library` 
 PKG_ENV                = @LD_LIBRARY_PATH_VAR@="$(EXTRA_PATH):$(@LD_LIBRARY_PATH_VAR@)" \ 
                  PATH="$(EXTRA_PATH):$(PATH)" \ 
                  TCLLIBPATH="$(TCLLIBPATH)" \ 
-                  TDBCMYSQL_LIBRARY=`@CYGPATH@ $(srcdir)/library` 
+                  TDBCPOSTGRES_LIBRARY=`@CYGPATH@ $(srcdir)/library` 
  
 TCLSH_PROG     = @TCLSH_PROG@ 
 TCLSH          = $(PKG_ENV) $(TCLSH_ENV) $(TCLSH_PROG) 
  
 #WISH_ENV      = TK_LIBRARY=`@CYGPATH@ $(TK_SRC_DIR)/library` 
 
 
</verbatim>

<hr><i>slawek added on 2009-07-15 17:36:34:</i><br>
Thanks, I've missed this somehow - now fixed.

Trying to do some hand testing, I see that tdbc::postgres gets a segmentation 
fault in Tdbcpostgres_Init.  There were two distinct problems: 
 
(1) the table of data types was lacking a NULL termination, causing the 
loop that was initialising the hash table in per-interp data to run off the end. 
 
(2) the code to install methods was looking for the tdbc::mysql::statement object, which of course should have been tdbc::postgres::statement. 
 
The following patch gets around the issue, and at least allows the library to load. 
 
<verbatim> 
--- tdbcpostgres/generic/tdbcpostgres.c 
+++ tdbcpostgres/generic/tdbcpostgres.c 
@@ -151,16 +151,17 @@ 
        if (--(stmt->refCount) <= 0) {          \ 
            DeleteStatement(stmt);              \ 
        }                                       \ 
     } while(0) 
  
-typedef struct MysqlDataType { 
+typedef struct PostgresDataType { 
     const char* name;          /* Type name */ 
     int num;                   /* Type number */ 
-} MysqlDataType; 
-static const MysqlDataType dataTypes[] = { 
-    { "varchar",    0 } 
+} PostgresDataType; 
+static const PostgresDataType dataTypes[] = { 
+    { "varchar",    0 }, 
+    { NULL,        0 } 
 }; 
  
  
 /* Configuration options for Postgres connections */ 
  
@@ -1546,11 +1547,11 @@ 
                                     Tcl_NewStringObj(tokenStr+1, tokenLen-1)); 
            break; 
  
        case ';': 
            Tcl_SetObjResult(interp, 
-                            Tcl_NewStringObj("tdbc::mysql" 
+                            Tcl_NewStringObj("tdbc::postgres" 
                                              " does not support semicolons " 
                                              "in statements", -1)); 
            goto freeNativeSql; 
            break; 
  
@@ -2001,11 +2002,11 @@ 
        Tcl_DecrRefCount(nameObj); 
     } 
  
     /* Look up the 'statement' class */ 
  
-    nameObj = Tcl_NewStringObj("::tdbc::mysql::statement", -1); 
+    nameObj = Tcl_NewStringObj("::tdbc::postgres::statement", -1); 
     Tcl_IncrRefCount(nameObj); 
     if ((curClassObject = Tcl_GetObjectFromObj(interp, nameObj)) == NULL) { 
        Tcl_DecrRefCount(nameObj); 
        return TCL_ERROR; 
     } 
 
 
</verbatim>

<hr><i>slawek added on 2009-07-15 17:34:16:</i><br>
Fixed ealier, not pulled.

A lot of the code in tdbcpostgres.c was obviously cut-and-pasted from tdbcmysql.c.  This is a Good Thing (good programmers borrow, great programmers steal). But at least you should go through and do a global search-and-replace of mysql with postgres, so that the two extensions don't interfere and so that the commentary matches the database.

<hr><i>slawek added on 2009-07-15 17:32:05:</i><br>
I'm regularly checking for it and exterminating such things with sed. This time I fogot to do it. 

An exception raised by 'my commit' (in method 'transaction') leaves TRANSACTION open.  
 
This behavior was observed using sqlite3 driver with timeouts enabled.  
 
I suppose that 'my rollback' could also raise an exception, in which case the TRANSACTION wouldn't be closed as well.  
 
Does this mean that 'transaction' method shouldn't be used with timeouts enabled?

<hr /><i>kbk added on 2011-02-21 05:28:20 UTC:</i><br />
Emailed to original submitter: 
<verbatim> 
If 'commit' fails, I'm not sure what the correct action is!  I can 
certainly attempt to 'rollback' after an error on 'commit', but 
a failed rollback really has nowhere else to go, as I understand it. 
(And I thought that a failed 'commit' was supposed to initiate 
a rollback: did I err?) 
 
The code in question looks like the following.  I propose adding 
the stanza between tbe two comments, so that commit errors are 
reported and rollback attempted. (And removing the commits 
in the [switch] cases, since they're handled up above) 
Richard, does this look as if it might fix the issue in question? 
 
Kevin 
 
    method transaction {script} { 
    my begintransaction 
    set status [catch {uplevel 1 $script} result options] 
 
    # Propose adding the following code: vvvvvvvvvvvvvvvvvvvv 
 
    if {$status in {0 2 3 4}} { 
        set status2 [catch {my commit} result2 options2] 
        if {$status2 == 1} { 
        set status 1 
        set result $result2 
        set options $options2 
        } 
    } 
 
    # End of added code ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
 
    switch -exact -- $status { 
        0 { 
        my commit ; #delete this when the commit is added above 
        } 
        2 - 3 - 4 { 
        set options [dict merge {-level 1} \
                    $options[set options {}]] 
        dict incr options -level 
        my commit ; #delete this when the commit is added above 
        } 
        default { 
        my rollback 
        } 
    } 
    return -options $options $result 
    }  
</verbatim>

<hr /><i>kbk added on 2011-02-22 02:56:32 UTC:</i><br />
Fixed in [7413b791cb], please retest.

When doing a join on tables whaving columns with same name like this: 
 
    select a.name, b.name from t1 a, t2 b where a.id = b.id; 
 
the tdbc::sqlite driver will only return one 'name' key in a result dict. A result list will contain both values, but the columnvariable will contain the same column name twice.

<hr><i>kbk added on 2009-10-27 01:09:56:</i><br>
This is being recorded as a 'known bug'. It's essentially unfixable 
until we convert the SQLite3 driver over to using C, because that's 
where it's tripping over the duplicate names.

<hr><i>kbk added on 2009-10-27 01:10:40:</i><br>
Oh, yeah. It can be fixed by using <B>AS</B> clauses to disambiguate the 
column names.

The INSTALL.tcl file requires Tk for two messages.  
 
I'd suggest if Tk is not found the messages are displayed to stdout via puts.  
 
Not all tdbc users will be using Tk.

<hr><i>anonymous claiming to be dereckson added on 2010-06-30 03:21:57:</i><br>
Currently, tk is only required to build tdbc::mysql

Here's the patch for bringing TDBC more strongly in line with Tcl documentation requirements. This allows its documentation to be built as part of Tcl's HTML doc build.

<hr><i>anonymous added on 2010-01-10 01:40:24:</i><br>
Index: Tdbc_Init.3 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/Tdbc_Init.3,v 
retrieving revision 1.1.1.1 
retrieving revision 1.3 
diff -u -r1.1.1.1 -r1.3 
--- Tdbc_Init.3	21 Apr 2009 02:44:27 -0000	1.1.1.1 
+++ Tdbc_Init.3	10 Jan 2010 01:32:14 -0000	1.3 
@@ -42,10 +42,6 @@ 
 .\"	# BS - start boxed text 
 .\"	# ^y = starting y location 
 .\"	# ^b = 1 
-.br 
-.\"	# BS - start boxed text 
-.\"	# ^y = starting y location 
-.\"	# ^b = 1 
 .de BS 
 .br 
 .mk ^y 
@@ -94,15 +90,16 @@ 
 .SH SYNOPSIS 
 .nf 
 \fB#include <tdbc.h>\fR 
-.sp 
+ 
 int 
 \fBTdbc_Init\fR(\fIinterp\fR) 
-.sp 
+ 
 Tcl_Obj * 
 \fBTdbc_TokenizeSql\fR(\fIinterp, sqlcode\fR) 
-.sp 
+ 
 const char * 
 \fBTdbc_MapSqlState\fR(\fIstate\fR) 
+.fi 
 .SH ARGUMENTS 
 .AS "Tcl_Interp" statement in/out 
 .AP Tcl_Interp *interp in/out 
Index: tdbc.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -47,17 +47,18 @@ 
 .SH "NAME" 
 tdbc \- Tcl Database Connectivity 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
-package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
-\fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
+package require \fBtdbc::\fIdriver version\fR 
+ 
+\fBtdbc::\fIdriver\fB::connection create \fIdb\fR ?\fI\-option value\fR...? 
+.fi 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
 Tcl Database Connectivity (TDBC) is a common interface for Tcl 
 programs to access SQL databases. It is implemented by a series of 
-database \fIdrivers:\fR separate modules, each of which adapts Tcl to 
+database \fIdrivers\fR: separate modules, each of which adapts Tcl to 
 the interface of one particular database system.  All of the drivers 
 implement a common series of commands for manipulating the database. 
 These commands are all named dynamically, since they all represent 
Index: tdbc_connection.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_connection.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_connection.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_connection.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -47,46 +47,40 @@ 
 .SH "NAME" 
 tdbc::connection \- TDBC connection object 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
-package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
-\fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
-.sp 
-\fIdb\fR \fBconfigure\fR ?\fI-option value\fR...? 
-.sp 
-\fIdb\fR \fBclose\fR 
-.sp 
-\fIdb\fR \fBprepare\fR \fIsql-code\fR 
-.sp 
-\fIdb\fR \fBpreparecall\fR \fIcall\fR 
-.sp 
-\fIdb\fR \fBstatements\fR 
-.sp 
-\fIdb\fR \fBresultsets\fR 
-.sp 
-\fIdb\fR \fBtables\fR ?\fIpattern\fR? 
-.sp 
-\fIdb\fR \fBcolumns\fR \fItable\fR ?\fIpattern\fR? 
-.sp 
-\fIdb\fR \fBbegintransaction\fR 
-.sp 
-\fIdb\fR \fBcommit\fR 
-.sp 
-\fIdb\fR \fBrollback\fR 
-.sp 
-\fIdb\fR \fBtransaction\fR \fIscript\fR 
-.sp 
-\fIdb\fR \fBallrows\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIsql-code\fR ?\fIdictionary\fR? 
-.sp 
-\fIdb\fR \fBforeach\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?--? \fIvarName\fR \fIsqlcode\fR ?\fIdictionary\fR? \fIscript\fR 
+package require \fBtdbc::\fIdriver version\fR 
+ 
+\fBtdbc::\fIdriver\fB::connection create \fIdb\fR ?\fI\-option value\fR...? 
+ 
+\fIdb \fBconfigure\fR ?\fI\-option value\fR...? 
+\fIdb \fBclose\fR 
+\fIdb \fBprepare \fIsql-code\fR 
+\fIdb \fBpreparecall \fIcall\fR 
+\fIdb \fBstatements\fR 
+\fIdb \fBresultsets\fR 
+\fIdb \fBtables\fR ?\fIpattern\fR? 
+\fIdb \fBcolumns \fItable\fR ?\fIpattern\fR? 
+\fIdb \fBbegintransaction\fR 
+\fIdb \fBcommit\fR 
+\fIdb \fBrollback\fR 
+\fIdb \fBtransaction \fIscript\fR 
+.fi 
+.ad l 
+.in 14 
+.ti 7 
+\fIdb \fBallrows\fR ?\fB\-as lists\fR|\fBdicts\fR? ?\fB\-columnsvariable \fIname\fR? ?\fB\-\-\fR? \fIsql-code\fR ?\fIdictionary\fR? 
+.br 
+.ti 7 
+\fIdb \fBforeach\fR ?\fB\-as lists\fR|\fBdicts\fR? ?\fB\-columnsvariable \fIname\fR? ?\fB\-\-\fR? \fIvarName sql-code\fR ?\fIdictionary\fR? \fIscript\fR 
+.ad b 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
 Every database driver for TDBC (Tcl DataBase Connectivity) implements 
 a \fIconnection\fR object that represents a connection to a database. 
 By convention, this object is created by the command, 
-\fBtdbc::\fR\fIdriver\fR\fB::connection\fR \fBcreate\fR. 
+\fBtdbc::\fIdriver\fB::connection create\fR. 
 This command accepts the name of a Tcl command that will represent the 
 connection and a possible set of options (see \fBCONFIGURATION 
 OPTIONS\fR). It establishes a connection to the database and returns 
@@ -95,7 +89,7 @@ 
 The \fBconfigure\fR object command on a database connection, if 
 presented with no arguments, returns a list of alternating keywords 
 and values representing the connection's current configuration. If 
-presented with a single argument \fI-option\fR, it returns the 
+presented with a single argument \fI\-option\fR, it returns the 
 configured value of the given option. Otherwise, it must be given an 
 even number of arguments which are alternating options and values. The 
 specified options receive the specified values, and nothing is 
@@ -112,18 +106,20 @@ 
 included. See \fBSQL STATEMENTS\fR for a further description of the 
 SQL that is accepted by this command. The return value is a 
 newly-created Tcl command that represents the statement. See 
-tdbc_statement(n) for the interface accepted by a statement. 
+\fBtdbc_statement\fR for the interface accepted by a statement. 
 .PP 
 On a database connection where the underlying database and driver 
 support stored procedures, the \fBpreparecall\fR 
 object command prepares a call to a stored procedure for execution. 
 The syntax of the stored procedure call is: 
-.sp 
+.PP 
+.CS 
 ?\fIresultvar\fR =? \fIprocname\fR(?\fIarg\fR ?, \fIarg\fR...?) 
-.sp 
+.CE 
+.PP 
 The return value is a 
 newly-created Tcl command that represents the statement. See 
-tdbc_statement(n) for the interface accepted by a statement. 
+\fBtdbc_statement\fR for the interface accepted by a statement. 
 .PP 
 The \fBstatements\fR object command returns a list of statements  
 that have been created by \fBprepare\fR and \fBpreparecall\fR 
@@ -199,19 +195,19 @@ 
 .PP 
 The \fBallrows\fR object command prepares a SQL statement (given by 
 the \fIsql-code\fR parameter) to execute against the database. 
-It then executes it (see \fBtdbc_statement(n)\fR for details) with the 
+It then executes it (see \fBtdbc_statement\fR for details) with the 
 optional \fIdictionary\fR parameter giving bind variables. Finally, 
 it uses the \fIallrows\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to construct a list of the results. Finally, both 
+\fBtdbc_resultset\fR) to construct a list of the results. Finally, both 
 result set and statement are closed. The return value is the list of 
 results.  
 .PP 
 The \fBforeach\fR object command prepares a SQL statement (given by 
 the \fIsql-code\fR parameter) to execute against the database. 
-It then executes it (see \fBtdbc_statement(n)\fR for details) with the 
+It then executes it (see \fBtdbc_statement\fR for details) with the 
 optional \fIdictionary\fR parameter giving bind variables. Finally, 
 it uses the \fIforeach\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to evaluate the given \fIscript\fR for each row of 
+\fBtdbc_resultset\fR) to evaluate the given \fIscript\fR for each row of 
 the results. Finally, both result set and statement are closed, even 
 if the given \fIscript\fR results in a \fBreturn\fR, an error, or 
 an unusual return code.  
@@ -219,29 +215,29 @@ 
 The configuration options accepted when the connection is created and 
 on the connection's \fBconfigure\fR object command include the 
 following, and may include others specific to a database driver. 
-.IP "\fB-encoding\fR \fIname\fR" 
+.IP "\fB\-encoding \fIname\fR" 
 Specifies the encoding to be used in connecting to the database. 
 The \fIname\fR should be one of the names accepted by the 
-\fBencoding(n)\fR command. This option is usually unnecessary; most 
+\fBencoding\fR command. This option is usually unnecessary; most 
 database drivers can figure out the encoding in use by themselves. 
-.IP "\fB-isolation\fR \fIlevel\fR" 
+.IP "\fB\-isolation \fIlevel\fR" 
 Specifies the transaction isolation level needed for transactions on 
 the database. The acceptable values for \fIlevel\fR are shown under 
 \fBTRANSACTION ISOLATION LEVELS\fR. 
-.IP "\fB-timeout\fR \fIms\fR" 
+.IP "\fB\-timeout \fIms\fR" 
 Specifies the maximum time to wait for a an operation database engine before 
 reporting an error to the caller. The \fIms\fR argument gives the 
 maximum time in milliseconds. A value of zero (the default) specifies 
 that the calling process is to wait indefinitely for database 
 operations. 
-.IP "\fB-readonly\fR \fIflag\fR" 
+.IP "\fB\-readonly \fIflag\fR" 
 Specifies that the connection will not modify the database (if the 
 Boolean parameter \fIflag\fR is true), or that it may modify the 
 database (if \fIflag\fR is false). If \fIflag\fR is true, this option 
 may have the effect of raising the transaction isolation level to 
 \fIreadonly\fR. 
-.SH "TRANSACTION ISOLATION LEVELS" 
-The acceptable values for the \fB-isolation\fR configuration option 
+.SS "TRANSACTION ISOLATION LEVELS" 
+The acceptable values for the \fB\-isolation\fR configuration option 
 are as follows: 
 .IP \fBreaduncommitted\fR 
 Allows the transaction to read "dirty", that is, uncommitted 
Index: tdbc_mapSqlState.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_mapSqlState.n,v 
retrieving revision 1.1.1.1 
retrieving revision 1.2 
diff -u -r1.1.1.1 -r1.2 
--- tdbc_mapSqlState.n	21 Apr 2009 02:44:27 -0000	1.1.1.1 
+++ tdbc_mapSqlState.n	10 Jan 2010 01:32:14 -0000	1.2 
@@ -59,9 +59,11 @@ 
 .SH "NAME" 
 tdbc::mapSqlState \- Map SQLSTATE to error class 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
+ 
 \fBtdbc::mapSqlState\fR \fIsqlstate\fR 
+.fi 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
Index: tdbc_resultset.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_resultset.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_resultset.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_resultset.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -59,32 +59,32 @@ 
 .SH "NAME" 
 tdbc::resultset \- TDBC result set object 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
 package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
+ 
 \fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
-.sp 
+ 
 \fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBprepare\fR \fIsql-code\fR\fB]\fR 
-.sp 
-\fBset\fR \fIresultset\fR \fB[\fR\fI$stmt\fR \fBexecute\fR ?\fIargs...\fR?
-.sp
+\fBset\fR \fIresultset\fR \fB[\fR\fI$stmt\fR \fBexecute\fR ?\fIargs...\fR?\fB]\fR 
+ 
 \fI$resultset\fR \fBcolumns\fR 
-.sp 
-\fI$resultset \fR \fBrowcount\fR 
-.sp 
+\fI$resultset\fR \fBrowcount\fR 
 \fI$resultset\fR \fBnextrow\fR ?\fB-as\fR \fBlists\fR|\fBdicts\fR? ?\fB--\fR? \fIvarname\fR 
-.sp 
 \fI$resultset\fR \fBnextlist\fR \fIvarname\fR 
-.sp 
 \fI$resultset\fR \fBnextdict\fR \fIvarname\fR 
-.sp 
+.fi 
+.ad l 
+.in 14 
+.ti 7 
 \fI$resultset\fR \fBallrows\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? 
-.sp 
-\fI$resultset\fR \fBforeach\fR ?\fB-as lists|dicts\fR? 
-?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarname\fR \fIscript\fR 
-.sp 
+.br 
+.ti 7 
+\fI$resultset\fR \fBforeach\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarname\fR \fIscript\fR 
+.br 
+.ti 7 
 \fI$resultset\fR \fBclose\fR 
+.ad b 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
Index: tdbc_statement.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_statement.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_statement.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_statement.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -58,32 +58,31 @@ 
 .SH "NAME" 
 tdbc::statement \- TDBC statement object 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
 package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
+ 
 \fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
-.sp 
+ 
 \fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBprepare\fR \fIsql-code\fR\fB]\fR 
-.sp 
-\fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBpreparecall\fR
-\fIcall\fR\fB]\fR 
-.sp 
+\fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBpreparecall\fR \fIcall\fR\fB]\fR 
+ 
 \fI$stmt\fR \fBparams\fR 
-.sp 
 \fI$stmt\fR \fBparamtype\fR ?\fIdirection\fR? \fItype\fR ?\fIprecision\fR? ?\fIscale\fR? 
-.sp 
 \fI$stmt\fR \fBexecute\fR ?\fIdict\fR? 
-.sp 
 \fI$stmt\fR \fBresultsets\fR 
-.sp 
+.fi 
+.ad l 
+.in 14 
+.ti 7 
 \fI$stmt\fR \fBallrows\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? ?\fIdict\fR 
-.sp 
-\fI$stmt\fR \fBforeach\fR ?\fB-as lists|dicts\fR? 
-?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarName\fR ?\fIdict\fR? 
-\fIscript\fR 
-.sp 
+.br 
+.ti 7 
+\fI$stmt\fR \fBforeach\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarName\fR ?\fIdict\fR? \fIscript\fR 
+.br 
+.ti 7 
 \fI$stmt\fR \fBclose\fR 
+.ad b 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
@@ -108,13 +107,17 @@ 
 .PP 
 The \fBpreparecall\fR object command against the connection accepts a 
 stylized statement in the form: 
-.sp 
+.PP 
+.CS 
 \fIprocname\fR \fB(\fR?\fB:\fR\fIvarname\fR? ?\fB,:\fR\fIvarname\fR...?\fB)\fR 
-.sp 
+.CE 
+.PP 
 or 
-.sp 
+.PP 
+.CS 
 \fIvarname\fR \fB=\fR \fIprocname\fR \fB(\fR?\fB:\fR\fIvarname\fR? ?\fB,:\fR\fIvarname\fR...?\fB)\fR 
-.sp 
+.CE 
+.PP 
 This statement represents a call to a stored procedure \fIprocname\fR in the 
 database. The variable name to the left of the equal sign (if 
 present), and all variable names that are parameters inside 
@@ -171,7 +174,7 @@ 
 found, its value becomes the bound variable's value. If none is found, 
 the bound variable is assigned a SQL NULL as its value.  Once 
 substitution is finished, the resulting statement is executed. The 
-return value is a result set object (see \fBtdbc_resultset(n)\fR for 
+return value is a result set object (see \fBtdbc_resultset\fR for 
 details). 
 .PP 
 The \fBresultsets\fR method returns a list of all the result sets that 
@@ -183,7 +186,7 @@ 
 optional \fIdict\fR parameter giving bind variables. After executing 
 the statement, 
 it uses the \fIallrows\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to construct a list of the results. Finally,  
+\fBtdbc_resultset\fR) to construct a list of the results. Finally,  
 the result set is closed. The return value is the list of 
 results.  
 .PP 
@@ -192,7 +195,7 @@ 
 optional \fIdict\fR parameter giving bind variables. After executing 
 the statement, 
 it uses the \fIforeach\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to evaluate the given \fIscript\fR for each row of 
+\fBtdbc_resultset\fR) to evaluate the given \fIscript\fR for each row of 
 the results. Finally, the result set is closed, even 
 if the given \fIscript\fR results in a \fBreturn\fR, an error, or 
 an unusual return code.  
@@ -203,6 +206,7 @@ 
 .SH "EXAMPLES" 
 The following code would look up a telephone number in a directory, 
 assuming an appropriate SQL schema: 
+.PP 
 .CS 
 package require tdbc::sqlite3 
 tdbc::sqlite3::connection create db phonebook.sqlite3 
Index: tdbc_tokenize.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_tokenize.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_tokenize.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_tokenize.n	10 Jan 2010 01:32:14 -0000	1.2 
@@ -59,9 +59,11 @@ 
 .SH "NAME" 
 tdbc::tokenize \- TDBC SQL tokenizer 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
+ 
 \fBtdbc::tokenize\fR \fIstring\fR 
+.fi 
 .BE 
 .SH "DESCRIPTION" 
 .PP 


<hr><i>anonymous claiming to be dkf added on 2010-01-10 11:56:13:</i><br>
Trying again to add the patch, having looked up fossil's formatting rules first: 
<verbatim>Index: Tdbc_Init.3 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/Tdbc_Init.3,v 
retrieving revision 1.1.1.1 
retrieving revision 1.3 
diff -u -r1.1.1.1 -r1.3 
--- Tdbc_Init.3	21 Apr 2009 02:44:27 -0000	1.1.1.1 
+++ Tdbc_Init.3	10 Jan 2010 01:32:14 -0000	1.3 
@@ -42,10 +42,6 @@ 
 .\"	# BS - start boxed text 
 .\"	# ^y = starting y location 
 .\"	# ^b = 1 
-.br 
-.\"	# BS - start boxed text 
-.\"	# ^y = starting y location 
-.\"	# ^b = 1 
 .de BS 
 .br 
 .mk ^y 
@@ -94,15 +90,16 @@ 
 .SH SYNOPSIS 
 .nf 
 \fB#include <tdbc.h>\fR 
-.sp 
+ 
 int 
 \fBTdbc_Init\fR(\fIinterp\fR) 
-.sp 
+ 
 Tcl_Obj * 
 \fBTdbc_TokenizeSql\fR(\fIinterp, sqlcode\fR) 
-.sp 
+ 
 const char * 
 \fBTdbc_MapSqlState\fR(\fIstate\fR) 
+.fi 
 .SH ARGUMENTS 
 .AS "Tcl_Interp" statement in/out 
 .AP Tcl_Interp *interp in/out 
Index: tdbc.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -47,17 +47,18 @@ 
 .SH "NAME" 
 tdbc \- Tcl Database Connectivity 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
-package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
-\fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
+package require \fBtdbc::\fIdriver version\fR 
+ 
+\fBtdbc::\fIdriver\fB::connection create \fIdb\fR ?\fI\-option value\fR...? 
+.fi 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
 Tcl Database Connectivity (TDBC) is a common interface for Tcl 
 programs to access SQL databases. It is implemented by a series of 
-database \fIdrivers:\fR separate modules, each of which adapts Tcl to 
+database \fIdrivers\fR: separate modules, each of which adapts Tcl to 
 the interface of one particular database system.  All of the drivers 
 implement a common series of commands for manipulating the database. 
 These commands are all named dynamically, since they all represent 
Index: tdbc_connection.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_connection.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_connection.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_connection.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -47,46 +47,40 @@ 
 .SH "NAME" 
 tdbc::connection \- TDBC connection object 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
-package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
-\fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
-.sp 
-\fIdb\fR \fBconfigure\fR ?\fI-option value\fR...? 
-.sp 
-\fIdb\fR \fBclose\fR 
-.sp 
-\fIdb\fR \fBprepare\fR \fIsql-code\fR 
-.sp 
-\fIdb\fR \fBpreparecall\fR \fIcall\fR 
-.sp 
-\fIdb\fR \fBstatements\fR 
-.sp 
-\fIdb\fR \fBresultsets\fR 
-.sp 
-\fIdb\fR \fBtables\fR ?\fIpattern\fR? 
-.sp 
-\fIdb\fR \fBcolumns\fR \fItable\fR ?\fIpattern\fR? 
-.sp 
-\fIdb\fR \fBbegintransaction\fR 
-.sp 
-\fIdb\fR \fBcommit\fR 
-.sp 
-\fIdb\fR \fBrollback\fR 
-.sp 
-\fIdb\fR \fBtransaction\fR \fIscript\fR 
-.sp 
-\fIdb\fR \fBallrows\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIsql-code\fR ?\fIdictionary\fR? 
-.sp 
-\fIdb\fR \fBforeach\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?--? \fIvarName\fR \fIsqlcode\fR ?\fIdictionary\fR? \fIscript\fR 
+package require \fBtdbc::\fIdriver version\fR 
+ 
+\fBtdbc::\fIdriver\fB::connection create \fIdb\fR ?\fI\-option value\fR...? 
+ 
+\fIdb \fBconfigure\fR ?\fI\-option value\fR...? 
+\fIdb \fBclose\fR 
+\fIdb \fBprepare \fIsql-code\fR 
+\fIdb \fBpreparecall \fIcall\fR 
+\fIdb \fBstatements\fR 
+\fIdb \fBresultsets\fR 
+\fIdb \fBtables\fR ?\fIpattern\fR? 
+\fIdb \fBcolumns \fItable\fR ?\fIpattern\fR? 
+\fIdb \fBbegintransaction\fR 
+\fIdb \fBcommit\fR 
+\fIdb \fBrollback\fR 
+\fIdb \fBtransaction \fIscript\fR 
+.fi 
+.ad l 
+.in 14 
+.ti 7 
+\fIdb \fBallrows\fR ?\fB\-as lists\fR|\fBdicts\fR? ?\fB\-columnsvariable \fIname\fR? ?\fB\-\-\fR? \fIsql-code\fR ?\fIdictionary\fR? 
+.br 
+.ti 7 
+\fIdb \fBforeach\fR ?\fB\-as lists\fR|\fBdicts\fR? ?\fB\-columnsvariable \fIname\fR? ?\fB\-\-\fR? \fIvarName sql-code\fR ?\fIdictionary\fR? \fIscript\fR 
+.ad b 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
 Every database driver for TDBC (Tcl DataBase Connectivity) implements 
 a \fIconnection\fR object that represents a connection to a database. 
 By convention, this object is created by the command, 
-\fBtdbc::\fR\fIdriver\fR\fB::connection\fR \fBcreate\fR. 
+\fBtdbc::\fIdriver\fB::connection create\fR. 
 This command accepts the name of a Tcl command that will represent the 
 connection and a possible set of options (see \fBCONFIGURATION 
 OPTIONS\fR). It establishes a connection to the database and returns 
@@ -95,7 +89,7 @@ 
 The \fBconfigure\fR object command on a database connection, if 
 presented with no arguments, returns a list of alternating keywords 
 and values representing the connection's current configuration. If 
-presented with a single argument \fI-option\fR, it returns the 
+presented with a single argument \fI\-option\fR, it returns the 
 configured value of the given option. Otherwise, it must be given an 
 even number of arguments which are alternating options and values. The 
 specified options receive the specified values, and nothing is 
@@ -112,18 +106,20 @@ 
 included. See \fBSQL STATEMENTS\fR for a further description of the 
 SQL that is accepted by this command. The return value is a 
 newly-created Tcl command that represents the statement. See 
-tdbc_statement(n) for the interface accepted by a statement. 
+\fBtdbc_statement\fR for the interface accepted by a statement. 
 .PP 
 On a database connection where the underlying database and driver 
 support stored procedures, the \fBpreparecall\fR 
 object command prepares a call to a stored procedure for execution. 
 The syntax of the stored procedure call is: 
-.sp 
+.PP 
+.CS 
 ?\fIresultvar\fR =? \fIprocname\fR(?\fIarg\fR ?, \fIarg\fR...?) 
-.sp 
+.CE 
+.PP 
 The return value is a 
 newly-created Tcl command that represents the statement. See 
-tdbc_statement(n) for the interface accepted by a statement. 
+\fBtdbc_statement\fR for the interface accepted by a statement. 
 .PP 
 The \fBstatements\fR object command returns a list of statements  
 that have been created by \fBprepare\fR and \fBpreparecall\fR 
@@ -199,19 +195,19 @@ 
 .PP 
 The \fBallrows\fR object command prepares a SQL statement (given by 
 the \fIsql-code\fR parameter) to execute against the database. 
-It then executes it (see \fBtdbc_statement(n)\fR for details) with the 
+It then executes it (see \fBtdbc_statement\fR for details) with the 
 optional \fIdictionary\fR parameter giving bind variables. Finally, 
 it uses the \fIallrows\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to construct a list of the results. Finally, both 
+\fBtdbc_resultset\fR) to construct a list of the results. Finally, both 
 result set and statement are closed. The return value is the list of 
 results.  
 .PP 
 The \fBforeach\fR object command prepares a SQL statement (given by 
 the \fIsql-code\fR parameter) to execute against the database. 
-It then executes it (see \fBtdbc_statement(n)\fR for details) with the 
+It then executes it (see \fBtdbc_statement\fR for details) with the 
 optional \fIdictionary\fR parameter giving bind variables. Finally, 
 it uses the \fIforeach\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to evaluate the given \fIscript\fR for each row of 
+\fBtdbc_resultset\fR) to evaluate the given \fIscript\fR for each row of 
 the results. Finally, both result set and statement are closed, even 
 if the given \fIscript\fR results in a \fBreturn\fR, an error, or 
 an unusual return code.  
@@ -219,29 +215,29 @@ 
 The configuration options accepted when the connection is created and 
 on the connection's \fBconfigure\fR object command include the 
 following, and may include others specific to a database driver. 
-.IP "\fB-encoding\fR \fIname\fR" 
+.IP "\fB\-encoding \fIname\fR" 
 Specifies the encoding to be used in connecting to the database. 
 The \fIname\fR should be one of the names accepted by the 
-\fBencoding(n)\fR command. This option is usually unnecessary; most 
+\fBencoding\fR command. This option is usually unnecessary; most 
 database drivers can figure out the encoding in use by themselves. 
-.IP "\fB-isolation\fR \fIlevel\fR" 
+.IP "\fB\-isolation \fIlevel\fR" 
 Specifies the transaction isolation level needed for transactions on 
 the database. The acceptable values for \fIlevel\fR are shown under 
 \fBTRANSACTION ISOLATION LEVELS\fR. 
-.IP "\fB-timeout\fR \fIms\fR" 
+.IP "\fB\-timeout \fIms\fR" 
 Specifies the maximum time to wait for a an operation database engine before 
 reporting an error to the caller. The \fIms\fR argument gives the 
 maximum time in milliseconds. A value of zero (the default) specifies 
 that the calling process is to wait indefinitely for database 
 operations. 
-.IP "\fB-readonly\fR \fIflag\fR" 
+.IP "\fB\-readonly \fIflag\fR" 
 Specifies that the connection will not modify the database (if the 
 Boolean parameter \fIflag\fR is true), or that it may modify the 
 database (if \fIflag\fR is false). If \fIflag\fR is true, this option 
 may have the effect of raising the transaction isolation level to 
 \fIreadonly\fR. 
-.SH "TRANSACTION ISOLATION LEVELS" 
-The acceptable values for the \fB-isolation\fR configuration option 
+.SS "TRANSACTION ISOLATION LEVELS" 
+The acceptable values for the \fB\-isolation\fR configuration option 
 are as follows: 
 .IP \fBreaduncommitted\fR 
 Allows the transaction to read "dirty", that is, uncommitted 
Index: tdbc_mapSqlState.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_mapSqlState.n,v 
retrieving revision 1.1.1.1 
retrieving revision 1.2 
diff -u -r1.1.1.1 -r1.2 
--- tdbc_mapSqlState.n	21 Apr 2009 02:44:27 -0000	1.1.1.1 
+++ tdbc_mapSqlState.n	10 Jan 2010 01:32:14 -0000	1.2 
@@ -59,9 +59,11 @@ 
 .SH "NAME" 
 tdbc::mapSqlState \- Map SQLSTATE to error class 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
+ 
 \fBtdbc::mapSqlState\fR \fIsqlstate\fR 
+.fi 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
Index: tdbc_resultset.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_resultset.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_resultset.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_resultset.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -59,32 +59,32 @@ 
 .SH "NAME" 
 tdbc::resultset \- TDBC result set object 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
 package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
+ 
 \fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
-.sp 
+ 
 \fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBprepare\fR \fIsql-code\fR\fB]\fR 
-.sp 
-\fBset\fR \fIresultset\fR \fB[\fR\fI$stmt\fR \fBexecute\fR ?\fIargs...\fR?
-.sp
+\fBset\fR \fIresultset\fR \fB[\fR\fI$stmt\fR \fBexecute\fR ?\fIargs...\fR?\fB]\fR 
+ 
 \fI$resultset\fR \fBcolumns\fR 
-.sp 
-\fI$resultset \fR \fBrowcount\fR 
-.sp 
+\fI$resultset\fR \fBrowcount\fR 
 \fI$resultset\fR \fBnextrow\fR ?\fB-as\fR \fBlists\fR|\fBdicts\fR? ?\fB--\fR? \fIvarname\fR 
-.sp 
 \fI$resultset\fR \fBnextlist\fR \fIvarname\fR 
-.sp 
 \fI$resultset\fR \fBnextdict\fR \fIvarname\fR 
-.sp 
+.fi 
+.ad l 
+.in 14 
+.ti 7 
 \fI$resultset\fR \fBallrows\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? 
-.sp 
-\fI$resultset\fR \fBforeach\fR ?\fB-as lists|dicts\fR? 
-?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarname\fR \fIscript\fR 
-.sp 
+.br 
+.ti 7 
+\fI$resultset\fR \fBforeach\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarname\fR \fIscript\fR 
+.br 
+.ti 7 
 \fI$resultset\fR \fBclose\fR 
+.ad b 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
Index: tdbc_statement.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_statement.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_statement.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_statement.n	10 Jan 2010 00:57:13 -0000	1.2 
@@ -58,32 +58,31 @@ 
 .SH "NAME" 
 tdbc::statement \- TDBC statement object 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
 package require \fBtdbc::\fR\fIdriver version\fR 
-.sp 
+ 
 \fBtdbc::\fR\fIdriver\fR\fB::connection create \fR\fIdb\fR \fI?\-option value\fR...? 
-.sp 
+ 
 \fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBprepare\fR \fIsql-code\fR\fB]\fR 
-.sp 
-\fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBpreparecall\fR
-\fIcall\fR\fB]\fR 
-.sp 
+\fBset\fR \fIstmt\fR \fB[\fR\fIdb\fR \fBpreparecall\fR \fIcall\fR\fB]\fR 
+ 
 \fI$stmt\fR \fBparams\fR 
-.sp 
 \fI$stmt\fR \fBparamtype\fR ?\fIdirection\fR? \fItype\fR ?\fIprecision\fR? ?\fIscale\fR? 
-.sp 
 \fI$stmt\fR \fBexecute\fR ?\fIdict\fR? 
-.sp 
 \fI$stmt\fR \fBresultsets\fR 
-.sp 
+.fi 
+.ad l 
+.in 14 
+.ti 7 
 \fI$stmt\fR \fBallrows\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? ?\fIdict\fR 
-.sp 
-\fI$stmt\fR \fBforeach\fR ?\fB-as lists|dicts\fR? 
-?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarName\fR ?\fIdict\fR? 
-\fIscript\fR 
-.sp 
+.br 
+.ti 7 
+\fI$stmt\fR \fBforeach\fR ?\fB-as lists|dicts\fR? ?\fB-columnsvariable\fR \fIname\fR? ?\fB--\fR? \fIvarName\fR ?\fIdict\fR? \fIscript\fR 
+.br 
+.ti 7 
 \fI$stmt\fR \fBclose\fR 
+.ad b 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
@@ -108,13 +107,17 @@ 
 .PP 
 The \fBpreparecall\fR object command against the connection accepts a 
 stylized statement in the form: 
-.sp 
+.PP 
+.CS 
 \fIprocname\fR \fB(\fR?\fB:\fR\fIvarname\fR? ?\fB,:\fR\fIvarname\fR...?\fB)\fR 
-.sp 
+.CE 
+.PP 
 or 
-.sp 
+.PP 
+.CS 
 \fIvarname\fR \fB=\fR \fIprocname\fR \fB(\fR?\fB:\fR\fIvarname\fR? ?\fB,:\fR\fIvarname\fR...?\fB)\fR 
-.sp 
+.CE 
+.PP 
 This statement represents a call to a stored procedure \fIprocname\fR in the 
 database. The variable name to the left of the equal sign (if 
 present), and all variable names that are parameters inside 
@@ -171,7 +174,7 @@ 
 found, its value becomes the bound variable's value. If none is found, 
 the bound variable is assigned a SQL NULL as its value.  Once 
 substitution is finished, the resulting statement is executed. The 
-return value is a result set object (see \fBtdbc_resultset(n)\fR for 
+return value is a result set object (see \fBtdbc_resultset\fR for 
 details). 
 .PP 
 The \fBresultsets\fR method returns a list of all the result sets that 
@@ -183,7 +186,7 @@ 
 optional \fIdict\fR parameter giving bind variables. After executing 
 the statement, 
 it uses the \fIallrows\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to construct a list of the results. Finally,  
+\fBtdbc_resultset\fR) to construct a list of the results. Finally,  
 the result set is closed. The return value is the list of 
 results.  
 .PP 
@@ -192,7 +195,7 @@ 
 optional \fIdict\fR parameter giving bind variables. After executing 
 the statement, 
 it uses the \fIforeach\fR object command on the result set (see 
-\fBtdbc_resultset(n)\fR) to evaluate the given \fIscript\fR for each row of 
+\fBtdbc_resultset\fR) to evaluate the given \fIscript\fR for each row of 
 the results. Finally, the result set is closed, even 
 if the given \fIscript\fR results in a \fBreturn\fR, an error, or 
 an unusual return code.  
@@ -203,6 +206,7 @@ 
 .SH "EXAMPLES" 
 The following code would look up a telephone number in a directory, 
 assuming an appropriate SQL schema: 
+.PP 
 .CS 
 package require tdbc::sqlite3 
 tdbc::sqlite3::connection create db phonebook.sqlite3 
Index: tdbc_tokenize.n 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/doc/tdbc_tokenize.n,v 
retrieving revision 1.1.1.3 
retrieving revision 1.2 
diff -u -r1.1.1.3 -r1.2 
--- tdbc_tokenize.n	21 Apr 2009 02:44:27 -0000	1.1.1.3 
+++ tdbc_tokenize.n	10 Jan 2010 01:32:14 -0000	1.2 
@@ -59,9 +59,11 @@ 
 .SH "NAME" 
 tdbc::tokenize \- TDBC SQL tokenizer 
 .SH "SYNOPSIS" 
+.nf 
 package require \fBtdbc 1.0\fR 
-.sp 
+ 
 \fBtdbc::tokenize\fR \fIstring\fR 
+.fi 
 .BE 
 .SH "DESCRIPTION" 
 .PP 
</verbatim>

<hr><i>kennykb added on 2010-04-06 21:24:31:</i><br>
Merged all documentation changes from the Tcl HEAD

There is a reference to a section "SQL STATEMENTS", but no such section exists. Fix by either adding the section or removing the reference.

<hr><i>kennykb added on 2010-04-06 23:32:25:</i><br>
Reference redirected to 'tdbc::statement', which is what was intended.

Here is a patch which makes the stub table 
as well as the StateLookup and commandTable 
"const", so those are placed in read-only 
memory, like Tcl does now with other stub 
(and other) tables. 
 
Regards, 
          Jan Nijtmans 
 
============================================= 
Index: generic/tdbcStubInit.c 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/generic/tdbcStubInit.c,v 
retrieving revision 1.1.1.4 
diff -c -r1.1.1.4 tdbcStubInit.c 
*** generic/tdbcStubInit.c	1 Feb 2009 22:41:57 -0000	1.1.1.4 
--- generic/tdbcStubInit.c	1 Mar 2010 20:15:03 -0000 
*************** 
*** 15,25 **** 
   
  #include "tdbcInt.h" 
   
! MODULE_SCOPE TdbcStubs tdbcStubs; 
   
  /* !BEGIN!: Do not edit below this line. */ 
   
! TdbcStubs tdbcStubs = { 
      TCL_STUB_MAGIC, 
      TDBC_STUBS_EPOCH, 
      TDBC_STUBS_REVISION, 
--- 15,25 ---- 
   
  #include "tdbcInt.h" 
   
! MODULE_SCOPE const TdbcStubs tdbcStubs; 
   
  /* !BEGIN!: Do not edit below this line. */ 
   
! const TdbcStubs tdbcStubs = { 
      TCL_STUB_MAGIC, 
      TDBC_STUBS_EPOCH, 
      TDBC_STUBS_REVISION, 
Index: generic/tdbcDecls.h 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/generic/tdbcDecls.h,v 
retrieving revision 1.1.1.3 
diff -c -r1.1.1.3 tdbcDecls.h 
*** generic/tdbcDecls.h	1 Feb 2009 22:41:57 -0000	1.1.1.3 
--- generic/tdbcDecls.h	1 Mar 2010 20:15:03 -0000 
*************** 
*** 50,56 **** 
      int magic; 
      int epoch; 
      int revision; 
!     struct TdbcStubHooks *hooks; 
   
      int (*tdbc_Init) (Tcl_Interp* interp); /* 0 */ 
      Tcl_Obj* (*tdbc_TokenizeSql) (Tcl_Interp* interp, const char* statement); /* 1 */ 
--- 50,56 ---- 
      int magic; 
      int epoch; 
      int revision; 
!     const struct TdbcStubHooks *hooks; 
   
      int (*tdbc_Init) (Tcl_Interp* interp); /* 0 */ 
      Tcl_Obj* (*tdbc_TokenizeSql) (Tcl_Interp* interp, const char* statement); /* 1 */ 
Index: generic/tdbcStubLib.c 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/generic/tdbcStubLib.c,v 
retrieving revision 1.1.1.2 
diff -c -r1.1.1.2 tdbcStubLib.c 
*** generic/tdbcStubLib.c	30 Dec 2008 19:08:12 -0000	1.1.1.2 
--- generic/tdbcStubLib.c	1 Mar 2010 20:15:03 -0000 
*************** 
*** 19,25 **** 
  #define USE_TDBC_STUBS 1 
  #include "tdbc.h" 
   
! const TdbcStubs* tdbcStubsPtr; 
   
  /* 
   *----------------------------------------------------------------------------- 
--- 19,26 ---- 
  #define USE_TDBC_STUBS 1 
  #include "tdbc.h" 
   
! MODULE_SCOPE const TdbcStubs* tdbcStubsPtr; 
! const TdbcStubs *tdbcStubsPtr = NULL; 
   
  /* 
   *----------------------------------------------------------------------------- 
*************** 
*** 57,63 **** 
      ClientData clientData = NULL; 
  				/* Client data for the package */ 
      const char* actualVersion;  /* Actual version of the package */ 
!     TdbcStubs* stubsPtr;	/* Stubs table for the public API */ 
   
      /* Load the package */ 
   
--- 58,64 ---- 
      ClientData clientData = NULL; 
  				/* Client data for the package */ 
      const char* actualVersion;  /* Actual version of the package */ 
!     const TdbcStubs* stubsPtr;	/* Stubs table for the public API */ 
   
      /* Load the package */ 
   
*************** 
*** 77,83 **** 
      if (actualVersion == NULL) { 
  	return NULL; 
      } else { 
! 	stubsPtr = (TdbcStubs*) clientData; 
  	if (stubsPtr->epoch != epoch) { 
  	    errorMsg = "mismatched epoch number"; 
  	} else if (stubsPtr->revision < revision) { 
--- 78,84 ---- 
      if (actualVersion == NULL) { 
  	return NULL; 
      } else { 
! 	stubsPtr = (const TdbcStubs*) clientData; 
  	if (stubsPtr->epoch != epoch) { 
  	    errorMsg = "mismatched epoch number"; 
  	} else if (stubsPtr->revision < revision) { 
Index: generic/tdbc.c 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/generic/tdbc.c,v 
retrieving revision 1.1.1.3 
diff -c -r1.1.1.3 tdbc.c 
*** generic/tdbc.c	1 Feb 2009 22:41:57 -0000	1.1.1.3 
--- generic/tdbc.c	1 Mar 2010 20:15:03 -0000 
*************** 
*** 22,32 **** 
  static int TdbcMapSqlStateObjCmd(ClientData unused, Tcl_Interp* interp, 
  				 int objc, Tcl_Obj *const objv[]); 
   
! MODULE_SCOPE TdbcStubs tdbcStubs; 
   
  /* Table of commands to create for TDBC */ 
   
! static struct TdbcCommand { 
      const char* name;		/* Name of the command */ 
      Tcl_ObjCmdProc* proc;	/* Command procedure */ 
  } commandTable[] = { 
--- 22,32 ---- 
  static int TdbcMapSqlStateObjCmd(ClientData unused, Tcl_Interp* interp, 
  				 int objc, Tcl_Obj *const objv[]); 
   
! MODULE_SCOPE const TdbcStubs tdbcStubs; 
   
  /* Table of commands to create for TDBC */ 
   
! static const struct TdbcCommand { 
      const char* name;		/* Name of the command */ 
      Tcl_ObjCmdProc* proc;	/* Command procedure */ 
  } commandTable[] = { 
*************** 
*** 37,43 **** 
   
  /* Table mapping SQLSTATE to error code */ 
   
! static struct SqlStateLookup { 
      const char* stateclass; 
      const char* message; 
  } StateLookup [] = { 
--- 37,43 ---- 
   
  /* Table mapping SQLSTATE to error code */ 
   
! static const struct SqlStateLookup { 
      const char* stateclass; 
      const char* message; 
  } StateLookup [] = { 
Index: tools/genStubs.tcl 
=================================================================== 
RCS file: /cvsroot/tcl/tdbc/tools/genStubs.tcl,v 
retrieving revision 1.1.1.1 
diff -c -r1.1.1.1 genStubs.tcl 
*** tools/genStubs.tcl	17 Dec 2008 18:00:35 -0000	1.1.1.1 
--- tools/genStubs.tcl	1 Mar 2010 20:15:03 -0000 
*************** 
*** 694,700 **** 
  	foreach hook $hooks($name) { 
  	    set capHook [string toupper [string index $hook 0]] 
  	    append capHook [string range $hook 1 end] 
! 	    append text "    struct ${capHook}Stubs *${hook}Stubs;\n" 
  	} 
  	append text "} ${capName}StubHooks;\n" 
      } 
--- 694,700 ---- 
  	foreach hook $hooks($name) { 
  	    set capHook [string toupper [string index $hook 0]] 
  	    append capHook [string range $hook 1 end] 
! 	    append text "    const struct ${capHook}Stubs *${hook}Stubs;\n" 
  	} 
  	append text "} ${capName}StubHooks;\n" 
      } 
*************** 
*** 702,708 **** 
      append text "    int magic;\n" 
      append text "    int epoch;\n" 
      append text "    int revision;\n" 
!     append text "    struct ${capName}StubHooks *hooks;\n\n" 
   
      emitSlots $name text 
   
--- 702,708 ---- 
      append text "    int magic;\n" 
      append text "    int epoch;\n" 
      append text "    int revision;\n" 
!     append text "    const struct ${capName}StubHooks *hooks;\n\n" 
   
      emitSlots $name text 
   
*************** 
*** 741,747 **** 
      set CAPName [string toupper $name] 
   
      if {[info exists hooks($name)]} { 
!  	append text "\nstatic ${capName}StubHooks ${name}StubHooks = \{\n" 
  	set sep "    " 
  	foreach sub $hooks($name) { 
  	    append text $sep "&${sub}Stubs" 
--- 741,747 ---- 
      set CAPName [string toupper $name] 
   
      if {[info exists hooks($name)]} { 
!  	append text "\nstatic const ${capName}StubHooks ${name}StubHooks = \{\n" 
  	set sep "    " 
  	foreach sub $hooks($name) { 
  	    append text $sep "&${sub}Stubs" 
*************** 
*** 749,755 **** 
  	} 
  	append text "\n\};\n" 
      } 
!     append text "\n${capName}Stubs ${name}Stubs = \{\n" 
      append text "    TCL_STUB_MAGIC,\n" 
      append text "    ${CAPName}_STUBS_EPOCH,\n" 
      append text "    ${CAPName}_STUBS_REVISION,\n" 
--- 749,755 ---- 
  	} 
  	append text "\n\};\n" 
      } 
!     append text "\nconst ${capName}Stubs ${name}Stubs = \{\n" 
      append text "    TCL_STUB_MAGIC,\n" 
      append text "    ${CAPName}_STUBS_EPOCH,\n" 
      append text "    ${CAPName}_STUBS_REVISION,\n"

<hr><i>kennykb added on 2010-04-06 22:59:59:</i><br>
Patches accepted (with a few minor tweaks to correct some linkage problems 
on mingw).

 
The HEAD of the Tcl bundle of tdbc contains 
patches to the doc files that are not reflected 
back in the 1.0b13 release.  I'd like the 
Tcl HEAD and some actual release of tdbc to 
reach agreement so that Tcl can be in the 
bundling business instead of the patching  
business. 
 
Appears that tdbc fossil has some commits 
since the 1.0b13 release as well.

<hr><i>kennykb added on 2010-04-06 21:27:56:</i><br>
HEAD changes to the documentation merged back upstream.

If the directory <prefix>/man/man3 doesn't exist, the Tdbc_Init.3 file gets installed as <prefix>/man/man3 instead of <prefix>/man/man3/Tdbc_Init.3. This can happen when omitting the docs while installing Tcl, eg: 
    make install-binaries install-libraries install-packages 
 
The problem is that the makefile doesn't create the man3 directory. It does create the man/mann directory. Adding a similar line for man/man3 in the install-doc target seems to fix the problem. 
 
--- ../pkgs/tdbc/Makefile.in~   2010-03-29 20:57:43.000000000 +0200 
+++ ../pkgs/tdbc/Makefile.in    2010-04-05 23:50:19.000000000 +0200 
@@ -229,6 +229,7 @@ 
 
 install-doc: doc 
        @mkdir -p $(DESTDIR)$(mandir)/mann 
+       @mkdir -p $(DESTDIR)$(mandir)/man3 
        @echo "Installing documentation in $(DESTDIR)$(mandir)" 
        @list='$(srcdir)/doc/*.3'; for i in $$list; do \ 
            echo "Installing $$i"; \

<hr><i>kennykb added on 2010-04-06 21:28:46:</i><br>
Fixed.

The statement object has a method "getSql" which is not document: 
<nowiki> 
<p>set statement [$db_name prepare {select PATH_ID from PATHS where PATH=:path and parent_id is null}] 
<p>::oo::Obj943372::Stmt::10 
<p>(bin) 71 % $statement getSql 
<p>select PATH_ID from PATHS where PATH=:path and parent_id is null 
<p>(bin) 72 %  
</nowiki>

The statement object currently has an (undocumented) method yielding the underlying sql statement used for the construction of the specific statement object. (using bind variables notation). 
request: add a similar method for the resultset object, showing the substituted values.  
 
Using the example from the man page: 
 
<nowiki> 
<p>package require tdbc::sqlite3 
<p>tdbc::sqlite3::connection create db phonebook.sqlite3 
<p>set statement [db prepare {
<p>    select phone_num from directory where first_name = :firstname and last_name = :lastname
<p> }] 
<p>set firstname Fred 
<p>set lastname Flintstone 
<p> 
<p>$statement getSql gives:  
<p><i>    select phone_num from directory where first_name = :firstname and last_name = :lastname </i> 
<p> 
<p>set rs [$statement execute] 
 
<p><b>Request:</b> 
<p>$rs getSql would give: 
<p> <i>select phone_num from directory where first_name = 'Fred' and last_name = 'Flintstone' </i> 
<p> 
<p> 
 
<p><b>Motivation:</b> this feature would be very helpfull in debugging.. 
</nowiki>

In sh scripting, the if comparison operator is = and not ==. 
 
Symptom: 
 
checking for ORACLE_HOME variable... test: x/usr/local/oracle8-client: unexpected operator 
/usr/local/oracle8-client 
 
Patch: 
 
--- configure.in.old    2010-06-30 02:54:09.000000000 +0000 
+++ configure.in        2010-06-30 02:44:58.000000000 +0000 
@@ -191,7 +191,7 @@ 
 #-------------------------------------------------------------------- 
 AC_MSG_CHECKING([for ORACLE_HOME variable]) 
 
-if  test x"${ORACLE_HOME}" == "x"; then 
+if  test x"${ORACLE_HOME}" = "x"; then 
     AC_MSG_ERROR("ORACLE_HOME environment variable is not set. Set it to oracle product directory containing rdbms dir."); 
 fi 
 AC_MSG_RESULT(${ORACLE_HOME})

<hr><i>anonymous added on 2010-06-30 03:00:25:</i><br>
patch: http://pastebin.com/sYzwBMXU

<hr><i>kennykb added on 2010-09-03 18:06:22:</i><br>
tdbc::oracle is in the repos in case anyone wants to pick up where Slavek left off. It's not part of the release, because it's not quite done.

On FreeBSD 8.0 with Oracle 8 client (oracle8-client-0.2.0_1 package), oci.h is in rdbms/demo and not in rdbms/public. 
 
The configure script needs *BOTH* directories as -D. 
 
Something like ORACLE_INCLUDE_SPEC="-I${ORACLE_INCLUDE_DIR} -I${ORACLE_HOME}/rdbms/demo" works.

<hr><i>anonymous claiming to be dereckson added on 2010-06-30 03:19:24:</i><br>
Patch: http://paste2.org/p/897729

<hr><i>kennykb added on 2010-09-03 18:08:26:</i><br>
tdbc::oracle is not part of any release; it's left in the repository in case anyone wants to take over the unfinished project.

ld -lclntsh fails. 
 
config.log with genuine configure.in: http://pastebin.com/NEFXXni9 
 
According those errors and under advice of a FreeBSD port maintainer, I tried -lm -lcompat (required on FreeBSD for cuserid function) 
 
config.log with -lm -lcompat: http://pastebin.com/nmAASZgH

<hr><i>kennykb added on 2010-09-03 18:11:31:</i><br>
tdbcoracle is not part of any release; it's in the repository in case someone else wants to pick up the unfinished project where Slavek left off.

A problem in tdbc preventing a lot of its uses with e.g. tdbcodbc + Microsoft SQL Server: @[alphanumerics] is always interpreted by tdbc as a host parameter, with no way to escape it. Transact-SQL has its own uses for @: it is the only way to pass parameters by name to stored procedures, to specify a freshly defined stored procedure's argument list,  to name and access @@error etc.  
 
I'd readily accept the fact that TDBC drivers fail to give access to *all* features for *every* underlying database interface. But being unable to pass *certain kinds of SQL statements* to an underlying engine is _not_ acceptable.  
 
E.g. if I have a DBI layer lacking output parameters (like, duh, current tdbcodbc), Transact-SQL would enable me to work around it by declaring a temporary @local, EXEC'ing sp @param=@local OUTPUT and then selecting @local AS result. But with TDBC, I have no such option: declaring @local is impossible, as the tokenizer will see a host parameter there. What bothers me here is not only that certain statements are impossible, but that they are impossible because TDBC is `too smart' and doing `too much' (as opposed to TDBC lacking some code). 
 
Some options to allow @'s while staying backward compatible: (1) allow @@ or maybe \@ to mean literal @, (2) allow tokenizer to be *reconfigured* to ignore @localname and handle only :paramname syntax as a host parameter, (3) make TDBC C-language part call overridden version of tokenize method, when this method is redefined, (4) introduce some weird TDBC-specific syntax like @@{ /* we just asked not to look for host parameters inside braces */ } and provide an option to enable the syntax, disabling it by default for compatibility. 
 
Both (1) and (2) are easy to implement, and any of (1) (2) (4) would make a great benefit for most users of MSSQL (Transact-SQL).

<hr /><i>kennykb added on 2011-02-20 22:31:26:</i><br />
The bug is indeed there and an appropriate modification is in progress as part of ongoing work that will also resolve issues with multiple result sets and with output parameters from stored procedures. ☺

<hr /><i>kennykb added on 2011-02-21 04:59:51:</i><br />
I actually went one better: @ is now a special character for substitution only in tdbc::sqlite3.  In all the other platforms, there's no need for it as a substitution character, and there *is* need for it as a user variable sigil. 
 
Also added multiple result sets, because it appears that SQL Server doesn't 
keep the values of @variables between calls. 

 
Trying out tdbc::sqlite3 under the tcl/pkgs system, 
I find that [package require tdbc::sqlite3] only works 
after install, or when the build directory happens to 
be a subdirectory of the source directory. 
 
In other situations, the path ../library/tdbcsqlite3.tcl 
relative to pkgIndex.tcl doesn't point to anything, so 
the provide script fails.

<hr><i>anonymous added on 2010-09-02 16:01:45:</i><br>
 
ok, I see that tdbc::sqlite3 wants to install using 
the TM configuration, so the more useful approach may 
be to look into how to make that work.

<hr><i>kennykb added on 2010-09-03 18:04:24:</i><br>
It should be able to, now. Thanks for the fix in the chat.

in SYNOPSIS section of 
tdbc::resultset - TDBC result set object 
 
$resultset allrows ?-as lists|dicts? ?-columnsvariable name? ?--? 
 
should be 
 
$resultset allrows ?-as lists|dicts? ?-columnsvariable name? ?--? script

<hr /><i>kbk added on 2011-02-21 05:08:51 UTC:</i><br />
Not so - the 'allrows' method doesn't take a script.

Start the install.tcl the following error occurs, but the installation seems to be corret 
--------------------------- 
 
Error in startup script 
--------------------------- 
expected boolean value but got "8.6b1.2" 
    while executing 
"if {[package present Tk]} { 
  tk_messageBox -type ok  -detail "Files installed in $instdir"  -message 
"TDBC drivers installed."  -icon info 
     } else ..." 
     (file "C:\xxxxxxxx.\Downloads\tdbc1.0b16-win32\INSTALL.tcl" line 38) 
---------------------------

Postgres 9.0 changed the default formatting of bytea fields returned in a select to 'hex'.  The default behaviour before was 'escape'.  This confuses the code in ResultSetNextrowMethod: 
 
<code> 
colObj = Tcl_SubstObj(interp, toSubst, TCL_SUBST_BACKSLASHES); 
</code> 
 
Since the hex formatted data is in the form \x68656c6c6f2c20776f726c64 (for "hello, world"), Tcl_SubstObj converts this to "d" 
 
Workarounds are to change the default in postgres.conf 
<verbatim> 
bytea_output = 'escape' 
</verbatim> 
 
or set it on the connection: 
 
<code> 
db allrows {set bytea_output = 'escape'} 
</code> 
 
Ideal would be teach ResultSetNextrowMethod about the hex format though, as this is the preferred format going forward. 
 
Code to reproduce: 
 
<verbatim> 
package require tdbc::postgres 
tdbc::postgres::connection create db -db wf_test 
db allrows {create temporary table foo (bar bytea)} 
db allrows {insert into foo (bar) values ('hello, world')} 
#db allrows {set bytea_output = 'escape'} 
puts [lindex [db allrows -as lists {select bar from foo}] 0 0] 
db close 
</verbatim> 
 
Expected output: "hello, world" 
 
Got: "d"

<hr /><i>kbk added on 2012-07-13 01:41:26 UTC:</i><br />
Fixed in [10d916626e5bf1bb0ccd77c0fcf7e034fa641567]

<verbatim> 
# start with tclsh.exe; tcl_patchLevel 8.6b1.2 and wait for the crash. 
rename exit orig_exit 
 
proc exit {{a 0}} { 
    puts "exit" 
    after idle [list ::orig_exit $a] 
} 
 
proc anything {} { 
    package require tdbc::odbc 
    puts "anything" 
} 
anything 
</verbatim>

<hr /><i>kbk added on 2012-07-13 01:52:49 UTC:</i><br />
Works On My Machine - please resubmit if this continues to fail post-8.6b3 
 

Hi, 
 
It appears that the tdbc::postgres adapter does not support semicolons in statements making it a bit difficult to create functions 
 
Looks like it was introduced here: 
 
http://mirror1.tcl.tk/tdbc/info/a922f6900b

<hr /><i>kbk added on 2012-07-13 01:57:15 UTC:</i><br />
tdbc is supposed to handle plain, "bread and butter" data manipulation requests (INSERT, SELECT, UPDATE, DELETE, and SP calls) from Tcl.  Sophisticated data 
definition tasks may remain beyond it. I'm leaving this incident open as a 
feature request, but SP creation will need a fair amount of work to get right, and will ordinarily be done through other tools in any event.

<hr /><i>kbk added on 2012-11-16 20:49:02 UTC:</i><br />
This is a postgresql-specific problem and is being closed out in the main repository with the repository split.

The GetCell function in generic/tdbcodbc.c uses the following variables, which are not initialized: 
 
 
    SQLLEN colLen;		/* Actual size of the return value, in bytes */ 
 
    SQLINTEGER colLong;		/* Integer value of the column */ 
 
    SQLBIGINT colWide;		/* Wide-integer value of the column */ 
 
    SQLDOUBLE colDouble;	/* Double value of the column */ 
 
 
 
This causes problems, e.g., at  
 
 
 
4143:	rc = SQLGetData(rdata->hStmt, i+1, SQL_C_SBIGINT, 
			(SQLPOINTER) &colWide, sizeof(colWide), &colLen); 
 
 
 
 
if colLen != sizeof(colLong), in which case colLong is not completely set. 
 
See for example this Tcl code: 
 
 
 
 
set stmt [$db_conn prepare {SELECT 1}] 
 
set res [$stmt execute] 
 
$res nextlist row 
 
puts "row: $row" 
 
$stmt close 
 
 
 
By adding a couple of printfs to generic/tdbcodbc.c 
 
 
 
4172        printf("sizeof(colLong) => %zu\n", sizeof(colLong)); 
 
4172        printf("         colLen => %ld\n", colLen); 
 
4173        printf("        colLong => %ld\n", colLong); 
 
 
I get 
 
sizeof(colLong) => 8 
 
         colLen => 4 
 
        colLong => 34359738369 
 
row: 34359738369 
 
 
To fix this, initialize the four variables at the top of this issue.

<hr /><i>kbk added on 2012-07-13 02:11:57 UTC:</i><br />
I strongly suspect that this problem was actually the problem where tdbc was failing to check for bigint support from ODBC prior to transferring bigints through SqlGetData.  Nevertheless, in a superabundance of caution I am adding the requested initialisation of output parameters.

<hr /><i>kbk added on 2012-07-13 02:12:35 UTC:</i><br />
Fixed in [b65e45ce102be0cfbd9e8fae787b0f5dfe150c32]

the postgresql driver, given a table with a column declared as 'fieldname boolean', '$db columns $t $f' returns {fieldname {name fieldname nullable 1}} where I would expect at least a type boolean element in the dict.

<hr /><i>kbk added on 2012-11-16 20:45:28 UTC:</i><br />
Closing this incident in the main TDBC repository since it is postgresql-specific. It will remain open in tdbc::postgresql until I can verify that it is fixed.

After [tdbc::sqlite3::connection create db mainfilename] , the db command can execute the SQL command to ATTACH an additional database file, and the tables in the attached file can be used, but the [db tables] and other introspection object commands do not show the additional tables. 
 
The workaround is to get the data from the attachName.sqlite_master table.

<hr /><i>kbk added on 2012-11-16 20:48:06 UTC:</i><br />
This is a sqlite3-specific problem and is being closed in the main tdbc repository with the repository split

Under Fedora 17, the mysql libraries are named as: 
 
/usr/lib64/mysql/libmysqlclient.so.18 
/usr/lib64/mysql/libmysqlclient.so.18.0.0 
/usr/lib64/mysql/libmysqld.so.0 
/usr/lib64/mysql/libmysqld.so.0.0.1 
 
I had to manually edit mysqlStubInit.c in order to make it work: 
 
static const char* mysqlSuffixes[] = { 
    "", ".18", ".17", ".16", ".15", NULL 
}; 
 
The code searches up to version 16.

<hr /><i>jan.nijtmans added on 2012-07-26 14:04:00 UTC:</i><br />
committed to trunk

TDBC fails to build properly on Unices where __attribute__((__visibility__("hidden"))) is supported. 
 
Cause of problem: Tdbc_Init() is defined in tdbc.c with storage class TDBCAPI, which is #defined as MODULE_SCOPE, which is in turn #defined as __attribute__((__visibility__("hidden"))), which means "do not make this symbol visible to dlsym() or ld.so". 
 
That's exactly backwards: extension *_Init routines *must* be visible to dlsym(), so should be declared and defined with storage class DLLEXPORT (not MODULE_SCOPE, not EXTERN, and especially not TCL_STORAGE_CLASS).

<hr /><i>anonymous claiming to be jenglish added on 2012-07-11 21:54:12 UTC:</i><br />
(hope this patch survives fossilization) 
 
--- tdbc.h.broken	2012-07-11 14:13:28.669980232 -0700 
+++ tdbc.h	2012-07-11 14:21:15.664986200 -0700 
@@ -28,17 +28,7 @@ 
 #   endif 
 #endif 
  
-#undef TCL_STORAGE_CLASS 
-#ifdef BUILD_tdbc 
-#   define TCL_STORAGE_CLASS DLLEXPORT 
-#else 
-#   define TCL_STORAGE_CLASS 
-#endif 
- 
-EXTERN int		Tdbc_Init(Tcl_Interp *interp); 
- 
-#undef TCL_STORAGE_CLASS 
-#define TCL_STORAGE_CLASS DLLIMPORT 
+DLLEXPORT int Tdbc_Init(Tcl_Interp *interp); 
  
 /* 
  * TDBC_VERSION and TDBC_PATCHLEVEL here must match the ones that 
--- tdbc.c.broken	2012-07-11 14:27:13.718553784 -0700 
+++ tdbc.c	2012-07-11 14:27:23.367086984 -0700 
@@ -191,7 +191,7 @@ 
  *----------------------------------------------------------------------------- 
  */ 
  
-TDBCAPI int 
+DLLEXPORT int 
 Tdbc_Init( 
     Tcl_Interp* interp		/* Tcl interpreter */ 
 ) { 


<hr /><i>jan.nijtmans added on 2012-07-11 22:51:33 UTC:</i><br />
Should be fixed now

Building tdbc and tdbcsqlite3 on windows using makefile.vc had some problems: 
 
- 64 bit compiler not recognised (change needed in tdbc/win/makefile.vc) 
 
- platform not recognised (change needed in tdbc/win/rules.vc) 
 
- MODULE_SCOPE compile error (change needed in tdbcInt.h) 
 
- missing win directory for tdbcsqlite3 
 
I can send the patches and missing tdbcsqlite3/win files, but could not attach them to this ticket. 
 
Jos.

<hr /><i>jan.nijtmans added on 2012-07-17 14:39:45 UTC:</i><br />
I was already working on that ;-) 
 
Everything done for tdbc, not yet for the other sub-packages.

<hr /><i>anonymous added on 2012-07-17 19:55:44 UTC:</i><br />
Thanks Jan, you want the win directory for tdbcsqlite3?

<hr /><i>jan.nijtmans added on 2012-08-07 07:50:04 UTC:</i><br />
Thanks, Jos, for your files. 
 
Please verify that everything is correct now.

(Submitted on behalf of a colleague - also mailed to the 'tcl-tdbc' list but that mail doesn't seem to have come through?) 
 
I am using tdbc's odbc driver to work with an MS SQL Server (2008) database.  I have run into a problem when writing code to create a stored procedure, specifically w.r.t. the syntax for a procedure's parameters.  SQL Server's "CREATE PROCEDURE" syntax (http://msdn.microsoft.com/en-us/library/ms187926%28v=sql.100%29.aspx) requires that a procedure's parameters be declared using the @ symbol preceding the name, e.g. @myvar 
Just doing this results in the connection's prepare method returning a statement whose params method returns a dict that has all of the stored procedure's parameters as bound variables.  If I precede the parameter specifications with an underscore then the params dict does not contain the parameters, they are not seen as bound variables (b.t.w. this is undocumented) but when executing the statement fails due to the sql command still having the underscore.  See examples below. 
 
Thanks 
Douglas 
 
<verbatim> 
(tools) 5 %   set con_str {Driver=SQL Server Native Client 10.0;Server=127.0.0.1\SQLEXPRESS;DATABASE=TDBC;UID=builder;PWD=bob;} 
Driver=SQL Server Native Client 10.0;Server=127.0.0.1\SQLEXPRESS;DATABASE=TDBC;UID=builder;PWD=bob; 
(tools) 6 % tdbc::odbc::connection create my_mssql_con $con_str 
::my_mssql_con 
(tools) 7 % set sql_stmt { 
>   CREATE PROCEDURE [ESS].[sp_commitsinsert] 
>     @commitRef nchar(64), 
>     @streamId int, 
>     @lastCommitId int, 
>     @events nchar(64), 
>     @metadata nchar(64) = NULL, 
>     @snapshot nchar(64) = NULL 
>   AS 
>     IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = @streamId AND s.lastCommitId != @lastCommitId) 
>       RAISERROR('Concurrency exception', 0, 0) 
>     ELSE 
>       INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) 
>       VALUES (@commitRef, @streamId, @lastCommitId, @events, @metadata, @snapshot) 
> } 
 
  CREATE PROCEDURE [ESS].[sp_commitsinsert] 
    @commitRef nchar(64), 
    @streamId int, 
    @lastCommitId int, 
    @events nchar(64), 
    @metadata nchar(64) = NULL, 
    @snapshot nchar(64) = NULL 
  AS 
    IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = @streamId AND s.lastCommitId != @lastCommitId) 
      RAISERROR('Concurrency exception', 0, 0) 
    ELSE 
      INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) 
      VALUES (@commitRef, @streamId, @lastCommitId, @events, @metadata, @snapshot) 
 
(tools) 8 % set stmt [my_mssql_con prepare $sql_stmt] 
::oo::Obj22::Stmt::1 
(tools) 9 % set param_dict {} 
(tools) 10 % set param_dict [$stmt params] 
commitRef {name commitRef direction in type wvarchar precision 255 scale 0} 
  streamId {name streamId direction in type wvarchar precision 255 scale 0}  
  lastCommitId {name lastCommitId direction in type wvarchar precision 255 scale 0}  
  events {name events direction in type wvarchar precision 255 scale 0}  
  metadata {name metadata direction in type wvarchar precision 255 scale 0}  
  snapshot {name snapshot direction in type wvarchar precision 255 scale 0} 
(tools) 11 % set args {} 
(tools) 12 % foreach v_name [dict keys $param_dict] arg $args { 
>   if { ($v_name ne {}) && ([dict get $param_dict $v_name direction] ne "out") } { 
>     dict set param_dict $v_name $arg 
>   } 
> } 
(tools) 13 % puts $param_dict 
commitRef {} streamId {} lastCommitId {} events {} metadata {} snapshot {} 
(tools) 14 % set resultset [$stmt execute $param_dict] 
[Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'PROCEDURE'. 
[Microsoft][SQL Server Native Client 10.0][SQL Server]Statement(s) could not be prepared. 
(executing the statement) 
(tools) 15 % 
(tools) 15 % 
(tools) 15 % set sql_stmt { 
>   CREATE PROCEDURE [ESS].[sp_commitsinsert] 
>     _@commitRef nchar(64), 
>     _@streamId int, 
>     _@lastCommitId int, 
>     _@events nchar(64), 
>     _@metadata nchar(64) = NULL, 
>     _@snapshot nchar(64) = NULL 
>   AS 
>     IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = _@streamId AND s.lastCommitId != _@lastCommitId) 
>       RAISERROR('Concurrency exception', 0, 0) 
>     ELSE 
>       INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) 
>       VALUES (_@commitRef, _@streamId, _@lastCommitId, _@events, _@metadata, _@snapshot) 
> } 
 
  CREATE PROCEDURE [ESS].[sp_commitsinsert] 
    _@commitRef nchar(64), 
    _@streamId int, 
    _@lastCommitId int, 
    _@events nchar(64), 
    _@metadata nchar(64) = NULL, 
    _@snapshot nchar(64) = NULL 
  AS 
    IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = _@streamId AND s.lastCommitId != _@lastCommitId) 
      RAISERROR('Concurrency exception', 0, 0) 
    ELSE 
      INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) 
      VALUES (_@commitRef, _@streamId, _@lastCommitId, _@events, _@metadata, _@snapshot) 
 
(tools) 16 % set stmt [my_mssql_con prepare $sql_stmt] 
::oo::Obj22::Stmt::2 
(tools) 17 % set param_dict {} 
(tools) 18 % set param_dict [$stmt params] 
(tools) 19 % set args {} 
(tools) 20 % foreach v_name [dict keys $param_dict] arg $args { 
>   if { ($v_name ne {}) && ([dict get $param_dict $v_name direction] ne "out") } { 
>     dict set param_dict $v_name $arg 
>   } 
> } 
(tools) 21 % puts $param_dict 
 
(tools) 22 % set resultset [$stmt execute $param_dict] 
[Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near '_@commitRef'. 
[Microsoft][SQL Server Native Client 10.0][SQL Server]Statement(s) could not be prepared. 
(executing the statement) 
(tools) 23 % 
</verbatim>

<hr /><i>anonymous claiming to be twylite added on 2012-11-16 11:41:01 UTC:</i><br />
While pushing TEA build scripts for tdbcodbc I seem to have accidentally pushed the branch 'td-prism-tokenise-mod' as well, which contains our fix for this problem (which is to remove the special behaviour of '@' in tdbcTokenize.c).

<hr /><i>kbk added on 2012-11-16 20:51:22 UTC:</i><br />
This problem is reported against ODBC specifically and is being closed out from the main repository in the repository split.

There is no makefile.vc for TDBC-ODBC, so Windows builds are not possible without Mingw32/Cygwin.   
 
Proposed makefile.vc and supporting files committed to branch td-win-tea.

<hr /><i>kbk added on 2012-11-16 20:52:24 UTC:</i><br />
This problem is ODBC-specific and is being closed out from the main repository.

<hr /><i>oehhar added on 2012-11-27 16:22:06 UTC:</i><br />
But where is the place to commit odbc-related issues ? 
I have also prepared a makefile.vc and are quite happy with it. 
Thank you, 
Harald

When trying to compile tdbc::odbc with msvc, I found the following issues in 
win\makefile.vc: 
 
  *  stub library is not installed 
  *  there are two rules for <b>pkgIndex.tcl</b>: No issue, but leads to a make warning 
  *  header files are not installed 
  *  <b>tdbcConfig.sh</b> is incorrect and not installed 
 
The following patch cures all of them: 
  *  stub library is copied to the same location as the <b>tdbc100.dll</b>. 
  *  header files are copied to the tcl include folder. 
  The destination folder is build as: <b>$(_INSTALLDIR)\..\include</b> 
  *  <b>tdbcConfig.sh</b> is installed to the same location as <b>tdbc100.dll</b>. 
  Within the generated <b>tdbcconfig.sh</b> file, the build locations are not usable, because they use relative paths. 
  There is one slash which should be a backslash, hardcoded in <b>tclconfig.sh.in</b>. 
   
I would appreciate, if someone could verify, if this is correct and if I used the 
desired path names. 
 
Thank you, 
Harald 
 
<verbatim> 
---makefile.vc.patch--- 
--- C:/test/tcl8.6.0/pkgs/tdbc1.0.0/win/makefile_ori.vc	Fri Nov 23 22:46:02 2012 
+++ C:/test/tcl8.6.0/pkgs/tdbc1.0.0/win/makefile.vc	Tue Nov 27 13:38:26 2012 
@@ -227,7 +227,7 @@ 
 BIN_INSTALL_DIR		= $(PRJ_INSTALL_DIR) 
 DOC_INSTALL_DIR		= $(PRJ_INSTALL_DIR) 
 SCRIPT_INSTALL_DIR	= $(PRJ_INSTALL_DIR) 
-INCLUDE_INSTALL_DIR	= $(_TCLDIR)\include 
+INCLUDE_INSTALL_DIR	= $(_INSTALLDIR)\..\include 
  
 ### The following paths CANNOT have spaces in them. 
 GENERICDIR	= $(ROOT)\generic 
@@ -462,22 +462,22 @@ 
 @TCL_VERSION@         $(TCL_DOTVERSION) 
 << 
  
-$(OUT_DIR)\pkgIndex.tcl: $(ROOT)\pkgIndex.tcl.in 
-	@nmakehlp -s << $** > $@ 
- 
-	type << > $@ 
-if {[catch {package require Tcl 8.5}]} return 
-package ifneeded $(PROJECT) $(DOTVERSION) \ 
- [list load [file join $$dir $(PRJLIBNAME)] $(PROJECT)] 
-<< 
+.PHONY: $(OUT_DIR)\tdbcConfig.sh 
  
 $(OUT_DIR)\tdbcConfig.sh: $(ROOT)\tdbcConfig.sh.in 
 	nmakehlp -s << $** > $@ 
-@TDBC_LIB_SPEC@              $(PRJLIBNAME) 
-@TDBC_STUB_LIB_SPEC@         $(PRJLIBNAME) 
-@TDBC_INCLUDE_SPEC@          -I$(LIB_INSTALL_DIR) 
-@TDBC_PRIVATE_INCLUDE_SPEC@  -I$(LIB_INSTALL_DIR) 
 @PACKAGE_VERSION@            $(DOTVERSION) 
+@PKG_LIB_FILE@               $(PRJLIBNAME) 
+@tdbc_LIB_SPEC@              $(LIB_INSTALL_DIR)\$(PRJLIBNAME) 
+@PKG_STUB_LIB_FILE@          $(PRJSTUBLIBNAME) 
+@tdbc_BUILD_STUB_LIB_SPEC@   $(PRJSTUBLIB) 
+@tdbc_STUB_LIB_SPEC@         $(LIB_INSTALL_DIR)\$(PRJSTUBLIBNAME) 
+@tdbc_BUILD_STUB_LIB_PATH@   $(PRJSTUBLIB) 
+@tdbc_STUB_LIB_PATH@         $(LIB_INSTALL_DIR)\$(PRJSTUBLIBNAME) 
+@tdbc_SRC_DIR@               $(ROOT) 
+@tdbc_INCLUDE_SPEC@          -I$(INCLUDE_INSTALL_DIR) 
+@tdbc_BUILD_INCLUDE_SPEC@    -I$(GENERICDIR) 
+@tdbc_LIB_DIR@               $(LIB_INSTALL_DIR) 
 << 
  
 $(TMP_DIR)\tdbcStubLib.obj : $(GENERICDIR)\tdbcStubLib.c 
@@ -495,12 +495,17 @@ 
 	@echo Installing binaries to '$(SCRIPT_INSTALL_DIR)' 
 	@if not exist "$(SCRIPT_INSTALL_DIR)" mkdir "$(SCRIPT_INSTALL_DIR)" 
 	@$(CPY) $(PRJLIB) "$(SCRIPT_INSTALL_DIR)" >NUL 
+	@$(CPY) $(PRJSTUBLIB) "$(LIB_INSTALL_DIR)" >NUL 
  
-install-libraries: $(OUT_DIR)\pkgIndex.tcl 
+install-libraries: $(OUT_DIR)\pkgIndex.tcl $(OUT_DIR)\tdbcConfig.sh 
 	@echo Installing libraries to '$(SCRIPT_INSTALL_DIR)' 
 	@if exist $(LIBDIR) $(CPY) $(LIBDIR)\*.tcl "$(SCRIPT_INSTALL_DIR)" 
 	@echo Installing package index in '$(SCRIPT_INSTALL_DIR)' 
 	@$(CPY) $(OUT_DIR)\pkgIndex.tcl "$(SCRIPT_INSTALL_DIR)" 
+	@$(CPY) $(OUT_DIR)\tdbcConfig.sh "$(SCRIPT_INSTALL_DIR)" 
+	@echo Installing header files in '$(INCLUDE_INSTALL_DIR)' 
+	@$(CPY) "$(GENERICDIR)\tdbc.h"      "$(INCLUDE_INSTALL_DIR)\" 
+	@$(CPY) "$(GENERICDIR)\tdbcDecls.h" "$(INCLUDE_INSTALL_DIR)\" 
  
 install-docs: 
 	@echo Installing documentation files to '$(DOC_INSTALL_DIR)' 
</verbatim>

Thank you, Twilite, for the tdbc::odbc makefile 
 
IMHO the macro <b>TCL_VERSION_REQ</b> is required to build the <b>pkgConfig.sh</b> file. 
 
Here is a possible patch: 
<verbatim> 
--- C:/test/TDBC1.0/tdbcodbc/win/makefile_twilite.vc	Tue Nov 27 17:24:46 2012 
+++ C:/test/TDBC1.0/tdbcodbc/win/makefile_twilite_n.vc	Tue Nov 27 17:29:49 2012 
@@ -177,6 +177,9 @@ 
 !if [echo DOTVERSION = \>> versions.vc] \ 
    && [nmakehlp -V ..\configure.in AC_INIT >> versions.vc] 
 !endif 
+!if [echo TCL_VERSION_REQ = \>> versions.vc] \ 
+   && [nmakehlp -V ..\configure.in TCL_VERSION_REQ >> versions.vc] 
+!endif 
 !include "versions.vc" 
  
 VERSION         = $(DOTVERSION:.=) 
</verbatim> 
 
Eventually, you could also adjust path management to the patch of this ticket: e226dbc23c 
It may eventually be used to locate the header files and stub lib of tdbc. 
 
Thank you, 
Harald

As a follow-up to [Tcl FRQ 3010352], 
 
Objective: simplify Stubs by 
 
- exporting only the minimally needed symbols, i.e. 
only Tdbc_Init, nothing more. 
 
- Eliminate the need for -DUSE_TDBC_STUBS 
 
For TclOO, this is already done, I have a 
corresponding patch for Tdbc available.

<hr /><i>anonymous added on 2011-11-07 10:05:24 UTC:</i><br />
Implementation available now in branch rfe-b4029dc351 
 
Kevin, is this suitable for the next beta? 
 
            Jan Nijtmans

<hr /><i>jan.nijtmans added on 2012-06-10 20:11:21 UTC:</i><br />
Now tested on Windows and UNIX, should work fine on all platforms