You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(3) |
Feb
(35) |
Mar
|
Apr
(10) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(13) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(7) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(26) |
2013 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(11) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Patrick D. <pat...@ac...> - 2009-02-24 18:23:03
|
Yes, went there and downloaded the source files. What I am saying is that the source does not appear to include all the makefile.vc files required to build the whole solution on windows. Here is a subset of what's in the source zip and cvs. The tdbcodbc, tdbcmysql and tdbcsqlite3 directories do not have a win directory under them or subsequent makefile.vc. You can see the tdbc directory does. Directory of C:\tdbc_src\tdbc 02/24/2009 10:20 AM <DIR> . 02/24/2009 10:20 AM <DIR> .. 02/24/2009 10:20 AM 3,285 aclocal.m4 02/24/2009 10:20 AM 7,481 ChangeLog 02/24/2009 10:20 AM 341,664 configure 02/24/2009 10:20 AM 8,762 configure.in 02/24/2009 10:20 AM <DIR> doc 02/24/2009 10:20 AM <DIR> generic 02/24/2009 10:20 AM <DIR> library 02/24/2009 10:20 AM 2,159 license.terms 02/24/2009 10:20 AM 17,757 Makefile.in 02/24/2009 10:20 AM 3,555 README 02/24/2009 10:20 AM <DIR> tclconfig 02/24/2009 10:20 AM 684 tdbcConfig.sh.in 02/24/2009 10:20 AM <DIR> tests 02/24/2009 10:20 AM <DIR> tools 02/24/2009 10:33 AM <DIR> win 8 File(s) 385,347 bytes Directory of C:\tdbc_src\tdbc\win 02/24/2009 10:33 AM <DIR> . 02/24/2009 10:33 AM <DIR> .. 02/24/2009 10:20 AM 16,701 makefile.vc 02/24/2009 10:20 AM 19,406 nmakehlp.c 02/24/2009 10:24 AM 90,624 nmakehlp.exe 02/24/2009 10:24 AM 14,078 nmakehlp.obj 02/24/2009 10:20 AM 19,034 rules.vc 02/24/2009 10:20 AM 1,091 tdbc.rc 02/24/2009 10:33 AM 125 versions.vc 7 File(s) 161,059 bytes Directory of C:\tdbc_src\tdbcmysql 02/24/2009 10:20 AM <DIR> . 02/24/2009 10:20 AM <DIR> .. 02/24/2009 10:20 AM 3,265 aclocal.m4 02/24/2009 10:20 AM 2,159 ChangeLog 02/24/2009 10:20 AM 391,195 configure 02/24/2009 10:20 AM 10,957 configure.in 02/24/2009 10:20 AM <DIR> doc 02/24/2009 10:20 AM <DIR> generic 02/24/2009 10:20 AM <DIR> library 02/24/2009 10:20 AM 2,159 license.terms 02/24/2009 10:20 AM 16,767 Makefile.in 02/24/2009 10:20 AM 3,044 README 02/24/2009 10:20 AM <DIR> tclconfig 02/24/2009 10:20 AM <DIR> tests 02/24/2009 10:20 AM 125 TODO 8 File(s) 429,671 bytes Directory of C:\tdbc_src\tdbcodbc 02/24/2009 10:20 AM <DIR> . 02/24/2009 10:20 AM <DIR> .. 02/24/2009 10:20 AM 3,265 aclocal.m4 02/24/2009 10:20 AM 7,529 ChangeLog 02/24/2009 10:20 AM 394,259 configure 02/24/2009 10:20 AM 11,405 configure.in 02/24/2009 10:20 AM <DIR> doc 02/24/2009 10:20 AM <DIR> generic 02/24/2009 10:20 AM <DIR> library 02/24/2009 10:20 AM 2,159 license.terms 02/24/2009 10:20 AM 16,381 Makefile.in 02/24/2009 10:20 AM 1,570 README 02/24/2009 10:20 AM <DIR> tclconfig 02/24/2009 10:20 AM <DIR> tests 02/24/2009 10:20 AM 28 TODO 8 File(s) 436,596 bytes Directory of C:\tdbc_src\tdbcsqlite3 02/24/2009 10:20 AM <DIR> . 02/24/2009 10:20 AM <DIR> .. 02/24/2009 10:20 AM 147 aclocal.m4 02/24/2009 10:20 AM 2,399 ChangeLog 02/24/2009 10:20 AM 92,364 configure 02/24/2009 10:20 AM 3,846 configure.in 02/24/2009 10:20 AM <DIR> doc 02/24/2009 10:20 AM <DIR> library 02/24/2009 10:20 AM 2,168 license.terms 02/24/2009 10:20 AM 10,285 Makefile.in 02/24/2009 10:20 AM 142 pkgIndex.tcl.in 02/24/2009 10:20 AM 1,609 README 02/24/2009 10:20 AM <DIR> tclconfig 02/24/2009 10:20 AM 155 tempTest.tcl 02/24/2009 10:20 AM <DIR> tests 9 File(s) 113,115 bytes -----Original Message----- From: Larry W. Virden [mailto:lv...@gm...] Sent: Tuesday, February 24, 2009 10:54 AM To: pat...@ac... Cc: ke...@ac...; tcl...@li... Subject: Re: [Tcl-tdbc] 8.5.6 support Recently Kevin posted this tip for getting that software: ==== Windows drivers are at http://preview.tinyurl.com/db2zw8 . Unix users can build from the ZIP files, downloadable by following the "If you're here to get the sources" instructions on the tdbc.tcl.tk front page. It's all still beta, of course. ==== |
From: Larry W. V. <lv...@gm...> - 2009-02-24 15:54:26
|
Recently Kevin posted this tip for getting that software: ==== Windows drivers are at http://preview.tinyurl.com/db2zw8 . Unix users can build from the ZIP files, downloadable by following the "If you're here to get the sources" instructions on the tdbc.tcl.tk front page. It's all still beta, of course. ==== On Tue, Feb 24, 2009 at 10:43 AM, Patrick Dunnigan <pat...@ac...> wrote: > Kevin I am attempting to compile tdbc for 8.5.6 on windows using vc++ (VS > 2008). I see a win directory and makefile.vc for the tdbc directory and it > appears to have build successfully against 8.5.6. > > However the win directory and makefile.vc for tdbcodbc, tdbcsqlite3, > tdbcmysql don't exist. Am I missing something? > > Thanks > > Patrick Dunnigan > > Email: pat...@ac... > > Visit us at www.activecompliance.com > > This e-mail message is intended only for the use of the individual or entity > to which it is addressed, and may contain information that is confidential. > If you are not the intended recipient, any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by reply email. > > -----Original Message----- > From: Kevin Kenny [mailto:kk...@ny...] > Sent: Monday, February 23, 2009 7:21 PM > To: pat...@ac... > Cc: tcl...@li... > Subject: Re: [Tcl-tdbc] 8.5.6 support > > Patrick Dunnigan wrote: >> I noticed in some of the writings that TDBC should support 8.5.6 with >> tcloo installed. However when I attempt this I get the following error: >> >> >> >> version conflict for package "Tcl": have 8.5.6, need 8.6 >> >> >> >> I suppose the version is compiled in the dll. Anyway to get the dll to >> support either release? > > Yeah, I have to look at it. It's not supposed to be doing that. > It worked once upon a time, but there were some unrelated bugs with > version management that I had to fix. I haven't been keeping up > the backport very aggressively. > > If someone else wants to have a look, too, I'd appreciate it. > I'm kind of swamped with paywork and home life just at the moment. > > -- > 73 de ke9tv/2, Kevin > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Tcl-tdbc mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-tdbc > -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.xanga.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. |
From: Patrick D. <pat...@ac...> - 2009-02-24 15:43:50
|
Kevin I am attempting to compile tdbc for 8.5.6 on windows using vc++ (VS 2008). I see a win directory and makefile.vc for the tdbc directory and it appears to have build successfully against 8.5.6. However the win directory and makefile.vc for tdbcodbc, tdbcsqlite3, tdbcmysql don't exist. Am I missing something? Thanks Patrick Dunnigan Email: pat...@ac... Visit us at www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. -----Original Message----- From: Kevin Kenny [mailto:kk...@ny...] Sent: Monday, February 23, 2009 7:21 PM To: pat...@ac... Cc: tcl...@li... Subject: Re: [Tcl-tdbc] 8.5.6 support Patrick Dunnigan wrote: > I noticed in some of the writings that TDBC should support 8.5.6 with > tcloo installed. However when I attempt this I get the following error: > > > > version conflict for package "Tcl": have 8.5.6, need 8.6 > > > > I suppose the version is compiled in the dll. Anyway to get the dll to > support either release? Yeah, I have to look at it. It's not supposed to be doing that. It worked once upon a time, but there were some unrelated bugs with version management that I had to fix. I haven't been keeping up the backport very aggressively. If someone else wants to have a look, too, I'd appreciate it. I'm kind of swamped with paywork and home life just at the moment. -- 73 de ke9tv/2, Kevin |
From: Twylite <tw...@cr...> - 2009-02-24 07:56:26
|
Hi, Yell if I'm completely misunderstanding the issue here but ... > From: Kevin Kenny [mailto:kk...@ny...] >> > select sod.productid into #temp1 from sales.salesorderdetail sod; >> > select th.productid into #temp2 from production.transactionhistory th; >> > select t1.productid, count(*) from #temp1 t1 join #temp2 t2 >> > on t1.productid = t2.productid >> > group by t1.productid >> > having count(*) > 100000; >> > >> > This would be impossible to do in three separate prepare / executes >> > That at least mildly surprises me, because I've dealt with other systems > where temp tables persisted as long as the session or until explicitly > dropped. No matter, I see what you're driving at. > Another use case: DB initialisation (table creation, population of initial values, etc.) is a complete pain if you can't issue multiple SQL commands (separated by semi-colons) in one call. Existing Tcl-to-DB interfaces can handle this. >> > I think a good compromise would be to only return the result set for the >> > final SQL statement and automatically pitch the rest. This is what we have >> > done in the past with batch sql in our in house library. Maybe determine >> This is pretty much what everything I've ever used (MSSQL, MySQL, PostgreSQL; bindings in various languages) does. And for that matter any sort of command-line tool that comes with the DB (mysql/pgsql command line clients). > I think > that a "$resultset nextresult" call - returning 1 if there are more > results and 0 otherwise - could be quite doable. (The command > in question would do SQLMoreResults, and if more results are > pending, would clean up bindings, call SQLCloseStmt(..., SQL_UNBIND), > and bind the columns anew for the next result set. > > In that case, I think I'd make the [foreach] and [allrows] methods, at > least on connection and statement objects, iterate each result set in > turn, updating the '-columnsvariable' in between result sets. > Is there actually a point to this? When you issue multiple SQL statements (semi-colon separated) you don't want the intermediate resultsets, just the last one. In fact trying to return the intermediate resultsets in this fashion actually makes the solution less usable, because you have to do extra work to filter out the intermediate stuff. Regards, Twylite |
From: Kevin K. <kk...@ny...> - 2009-02-24 00:19:23
|
Patrick Dunnigan wrote: > I noticed in some of the writings that TDBC should support 8.5.6 with > tcloo installed. However when I attempt this I get the following error: > > > > version conflict for package "Tcl": have 8.5.6, need 8.6 > > > > I suppose the version is compiled in the dll. Anyway to get the dll to > support either release? Yeah, I have to look at it. It's not supposed to be doing that. It worked once upon a time, but there were some unrelated bugs with version management that I had to fix. I haven't been keeping up the backport very aggressively. If someone else wants to have a look, too, I'd appreciate it. I'm kind of swamped with paywork and home life just at the moment. -- 73 de ke9tv/2, Kevin |
From: Patrick D. <pat...@ac...> - 2009-02-23 23:01:38
|
I noticed in some of the writings that TDBC should support 8.5.6 with tcloo installed. However when I attempt this I get the following error: version conflict for package "Tcl": have 8.5.6, need 8.6 I suppose the version is compiled in the dll. Anyway to get the dll to support either release? I use the freewrap program to create binaries, but it is currently on 8.5.6. Thanks Patrick Dunnigan Email: pat...@ac... Visit us at <file:///C:\Documents%20and%20Settings\pdunnigan\Application%20Data\Microsof t\Signatures\www.activecompliance.com> www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. |
From: Patrick D. <pat...@ac...> - 2009-02-23 14:29:32
|
Here are some explanations and examples I found of doing exactly this on an asp.net website. Different language and drivers of course but concepts exactly the same. This may provide good guidance. My guess is that at least with SQL Server, if you "set nocount on" at the beginning then insert, update and delete statements won't cause recordsets to be created. http://www.4guysfromrolla.com/webtech/083101-1.shtml and another using identities ... http://www.4guysfromrolla.com/webtech/tips/t122600-1.shtml Patrick Dunnigan Email: pat...@ac... Visit us at www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. -----Original Message----- From: Kevin Kenny [mailto:kk...@ny...] Sent: Saturday, February 21, 2009 1:15 AM To: pat...@ac... Cc: tcl...@li... Subject: Re: [Tcl-tdbc] batching sql Patrick Dunnigan wrote: > Neither the stored procedure or separating the statements work in this case. > I have a lot of sql that's quite dynamic so a stored proc doesn't work and > the separate prepare / executes don't seem to keep temp tables in play. > > Take for example the following (overlook the fact that this could be done > efficiency in one sql, this just represents something much more complex). > > select sod.productid into #temp1 from sales.salesorderdetail sod; > select th.productid into #temp2 from production.transactionhistory th; > select t1.productid, count(*) from #temp1 t1 join #temp2 t2 > on t1.productid = t2.productid > group by t1.productid > having count(*) > 100000; > > This would be impossible to do in three separate prepare / executes because > the temp table seems to get destroyed after the first execute. That at least mildly surprises me, because I've dealt with other systems where temp tables persisted as long as the session or until explicitly dropped. No matter, I see what you're driving at. > Here's a link on the MS site on batching. > http://msdn.microsoft.com/en-us/library/ms131033.aspx > > I think a good compromise would be to only return the result set for the > final SQL statement and automatically pitch the rest. This is what we have > done in the past with batch sql in our in house library. Maybe determine how > many semicolons there are in the sql and execute each one, destroy the > results until you get to the final one, then execute and create the result > set? The it's just a matter of documenting that the final result set is the > only one that will be returned. Actually, I'm thinking that the job may be easier than I thought, since all the metadata is associated with the 'result set' object. I think that a "$resultset nextresult" call - returning 1 if there are more results and 0 otherwise - could be quite doable. (The command in question would do SQLMoreResults, and if more results are pending, would clean up bindings, call SQLCloseStmt(..., SQL_UNBIND), and bind the columns anew for the next result set. In that case, I think I'd make the [foreach] and [allrows] methods, at least on connection and statement objects, iterate each result set in turn, updating the '-columnsvariable' in between result sets. Unfortunately, these interfaces don't seem to provide a good way to notify the program when we move on to the next result, which is why I'd make the 'resultset' object have an explicit external iterator to move between result sets. I'm open to better suggestions. -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-21 06:21:02
|
Patrick Dunnigan wrote: > My opinion is that this would be a very useful feature, I hope you agree. I > can help if you want but it doesn't appear that the tdbc odbc code is on > sourceforge. You're right, it's in a 'fossil' repository on http://tdbc.tcl.tk/ instead. To get the sources, go there, login as 'anonymous' with the 'Login' link in the toolbar, then click on 'Leaves' in the toolbar, click on latest open leaf (currently [8c373d4949]), and click the 'ZIP Archive' link in the last line of the first section. -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-21 06:13:28
|
Patrick Dunnigan wrote: > Neither the stored procedure or separating the statements work in this case. > I have a lot of sql that's quite dynamic so a stored proc doesn't work and > the separate prepare / executes don't seem to keep temp tables in play. > > Take for example the following (overlook the fact that this could be done > efficiency in one sql, this just represents something much more complex). > > select sod.productid into #temp1 from sales.salesorderdetail sod; > select th.productid into #temp2 from production.transactionhistory th; > select t1.productid, count(*) from #temp1 t1 join #temp2 t2 > on t1.productid = t2.productid > group by t1.productid > having count(*) > 100000; > > This would be impossible to do in three separate prepare / executes because > the temp table seems to get destroyed after the first execute. That at least mildly surprises me, because I've dealt with other systems where temp tables persisted as long as the session or until explicitly dropped. No matter, I see what you're driving at. > Here's a link on the MS site on batching. > http://msdn.microsoft.com/en-us/library/ms131033.aspx > > I think a good compromise would be to only return the result set for the > final SQL statement and automatically pitch the rest. This is what we have > done in the past with batch sql in our in house library. Maybe determine how > many semicolons there are in the sql and execute each one, destroy the > results until you get to the final one, then execute and create the result > set? The it's just a matter of documenting that the final result set is the > only one that will be returned. Actually, I'm thinking that the job may be easier than I thought, since all the metadata is associated with the 'result set' object. I think that a "$resultset nextresult" call - returning 1 if there are more results and 0 otherwise - could be quite doable. (The command in question would do SQLMoreResults, and if more results are pending, would clean up bindings, call SQLCloseStmt(..., SQL_UNBIND), and bind the columns anew for the next result set. In that case, I think I'd make the [foreach] and [allrows] methods, at least on connection and statement objects, iterate each result set in turn, updating the '-columnsvariable' in between result sets. Unfortunately, these interfaces don't seem to provide a good way to notify the program when we move on to the next result, which is why I'd make the 'resultset' object have an explicit external iterator to move between result sets. I'm open to better suggestions. -- 73 de ke9tv/2, Kevin |
From: Patrick D. <pat...@ac...> - 2009-02-20 23:40:00
|
Neither the stored procedure or separating the statements work in this case. I have a lot of sql that's quite dynamic so a stored proc doesn't work and the separate prepare / executes don't seem to keep temp tables in play. Take for example the following (overlook the fact that this could be done efficiency in one sql, this just represents something much more complex). select sod.productid into #temp1 from sales.salesorderdetail sod; select th.productid into #temp2 from production.transactionhistory th; select t1.productid, count(*) from #temp1 t1 join #temp2 t2 on t1.productid = t2.productid group by t1.productid having count(*) > 100000; This would be impossible to do in three separate prepare / executes because the temp table seems to get destroyed after the first execute. Here's a link on the MS site on batching. http://msdn.microsoft.com/en-us/library/ms131033.aspx I think a good compromise would be to only return the result set for the final SQL statement and automatically pitch the rest. This is what we have done in the past with batch sql in our in house library. Maybe determine how many semicolons there are in the sql and execute each one, destroy the results until you get to the final one, then execute and create the result set? The it's just a matter of documenting that the final result set is the only one that will be returned. My opinion is that this would be a very useful feature, I hope you agree. I can help if you want but it doesn't appear that the tdbc odbc code is on sourceforge. Here's an example script against adventureworks. package require tdbc::odbc set conn_string "DRIVER=SQL Server;SERVER=127.0.0.1,1433;DBQ=AdventureWorks;UID=test_user;PWD=test_user; APP=test_tdbc" tdbc::odbc::connection create db $conn_string set sql "select sod.productid into #temp1 from sales.salesorderdetail sod" set sql_exec [db prepare $sql] $sql_exec execute set sql "select th.productid into #temp2 from production.transactionhistory th" set sql_exec [db prepare $sql] $sql_exec execute set sql "select t1.productid, count(*) from #temp1 t1 join #temp2 t2 on t1.productid = t2.productid group by t1.productid having count(*) > 100000" set sql_exec [db prepare $sql] and the results. bin\tclsh test_tdbc.tcl [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name '#temp1'. [Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared. (executing the statement) while executing "my init ::oo::Obj12::Stmt::3" (in namespace inscope "::oo::Obj20" script line 1) invoked from within "::namespace inscope ::oo::Obj20 {my init} ::oo::Obj12::Stmt::3" ("uplevel" body line 1) invoked from within "uplevel 1 [list {*}[namespace code {my init}] $statement {*}$args]" (class "::tdbc::odbc::resultset" constructor line 3) invoked from within "::tdbc::odbc::resultset create ::oo::Obj19::ResultSet::1 ::oo::Obj12::Stmt::3" ("uplevel" body line 1) invoked from within "uplevel 1 [list $resultSetClass create $name [self] {*}$args]" (class "::tdbc::statement" method "execute" line 7) invoked from within "$sql_exec execute" invoked from within "set results [$sql_exec execute]" (file "test_tdbc.tcl" line 21) Patrick Dunnigan Email: pat...@ac... Visit us at www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. -----Original Message----- From: Kevin Kenny [mailto:kk...@ny...] Sent: Thursday, February 19, 2009 2:34 PM To: pat...@ac... Cc: tcl...@li... Subject: Re: [Tcl-tdbc] batching sql Patrick Dunnigan wrote: > Is there anyway that this semicolon restriction can be removed and leave > it up to the individual user of tdbc to make that decision? That's harder than it looks. The difficulty is that TDBC as specified doesn't deal with multiple result sets, and that's a complicated thing to add. Would it be possible either to orchestrate the statements with a Tcl procedure or else wrap them in a stored procedure in the database? -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-19 19:32:27
|
Patrick Dunnigan wrote: > Is there anyway that this semicolon restriction can be removed and leave > it up to the individual user of tdbc to make that decision? That's harder than it looks. The difficulty is that TDBC as specified doesn't deal with multiple result sets, and that's a complicated thing to add. Would it be possible either to orchestrate the statements with a Tcl procedure or else wrap them in a stored procedure in the database? -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-19 19:29:51
|
Patrick Dunnigan wrote: > Are there any resources wasted if I do the following: > > set sql "update mytable set column1 = 'ABC123'" > set result [[$conn prepare $sql] execute] > > > and don't call $result close? > > In other words, for update / insert / etc. statements do we have to call > $results close. > > Presently I am only calling $results close on select statements. However > some of these processes run for days, even weeks or months on end so I don't > want to cause a memory leak or whatever. Yes, all result sets, even ones of zero rows, must be closed. For INSERT, UPDATE and DELETE statements, I've taken to writing: $conn allrows {UPDATE mytable SET column1 = :input} because that makes a list of the zero rows of the result set and returns that empty list, cleaning up the prepared statement and the result set. I also tend to prepare my statements once in program initialization (or on demand) and keep them around. At least if there's a likelihood that I'll be using them more than once. -- 73 de ke9tv/2, Kevin |
From: Patrick D. <pat...@ac...> - 2009-02-19 17:39:33
|
I would like to batch up some SQL. Most RDBMS support the semicolon to signify the separation of two sql statements. This is especially important when you have very complex SQLs that rely on temp or derived table. tdbc::odbc does not support semicolons in statements I know that the MS SQL ODBC drivers themselves support batched SQL using semicolons (System.Data.Odbc namespace, .NET Framework Data Provider for ODBC) Is there anyway that this semicolon restriction can be removed and leave it up to the individual user of tdbc to make that decision? Log below: Thanks, Patrick tdbc_query-> 2009-02-19 12:24:42 set nocount on; delete from application_registry where app_name = 'ce_poller' and app_instance = 'DEV351_ATLLNXDEV04'; insert into application_registry (app_name, app_instance, master) values ('ce_poller', 'DEV351_ATLLNXDEV04',1); select @@IDENTITY tdbc::odbc does not support semicolons in statements while executing "my init $connection $sqlcode" (class "::tdbc::odbc::statement" constructor line 5) invoked from within "$statementClass create Stmt::[incr statementSeq] [self] $sqlCode" (class "::tdbc::connection" method "prepare" line 4) invoked from within "$conn prepare $sql" (procedure "tdbc_query" line 6) invoked from within "tdbc_query $conn $sql" invoked from within "set result [tdbc_query $conn $sql]" (file "ce_poller.tcl" line 206) Patrick Dunnigan Office 678-383-4800 Cell 703-459-7150 Email: pat...@ac... Visit us at <file:///C:\Documents%20and%20Settings\pdunnigan\Application%20Data\Microsof t\Signatures\www.activecompliance.com> www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. |
From: Patrick D. <pat...@ac...> - 2009-02-19 16:12:33
|
Are there any resources wasted if I do the following: set sql "update mytable set column1 = 'ABC123'" set result [[$conn prepare $sql] execute] and don't call $result close? In other words, for update / insert / etc. statements do we have to call $results close. Presently I am only calling $results close on select statements. However some of these processes run for days, even weeks or months on end so I don't want to cause a memory leak or whatever. Thanks, Patrick Dunnigan Email: pat...@ac... Visit us at www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. -----Original Message----- From: Kevin Kenny [mailto:kk...@ny...] Sent: Wednesday, February 18, 2009 12:39 AM To: pat...@ac... Cc: tcl...@li... Subject: Re: [Tcl-tdbc] $resultset close Yes, it's required. You can have as many prepared statements per connection as you please, and as many result sets per statement as you please. Close them when you're done with them. -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-18 05:37:01
|
Patrick Dunnigan wrote: > In the documentation we have the following: > > > > /$resultset/ *close* > > The *close* object command deletes the result set and frees any > associated system resources. > > > > If you do not close the result set each time, does tdbc automatically > clean up the system resources on the subsequent prepare / execute? In > other words, besides being good practice is it required? Yes, it's required. You can have as many prepared statements per connection as you please, and as many result sets per statement as you please. Close them when you're done with them. -- 73 de ke9tv/2, Kevin |
From: Patrick D. <pat...@ac...> - 2009-02-17 17:27:45
|
In the documentation we have the following: $resultset close The close object command deletes the result set and frees any associated system resources. If you do not close the result set each time, does tdbc automatically clean up the system resources on the subsequent prepare / execute? In other words, besides being good practice is it required? Thanks Patrick Dunnigan Email: pat...@ac... Visit us at <file:///C:\Documents%20and%20Settings\pdunnigan\Application%20Data\Microsof t\Signatures\www.activecompliance.com> www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. |
From: Kevin K. <kk...@ny...> - 2009-02-16 21:13:44
|
I've cut yet another new release, labeled 1.0b9. The chief change is that I've fixed a bad bug in tdbc::odbc with the handling of large objects (greater than 512 characters), where the code as it stood would fail, up to and including corrupting memory, if a cell of a database row contained any object longer than the 512-character mark. Thanks to Patrick Dunnigan for pointing out this bug. -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-15 00:12:35
|
I've just merged TDBC 1.0b8 into the Tcl HEAD. http://tdbc.tcl.tk/ has the new version as a ZIP of the source code, including the available drivers. Windows binaries of the drivers, and HTML versions of the man pages are available for download from https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160 The Windows binaries should now install cleanly by running the INSTALL.tcl script in tclsh86.exe or wish86.exe. Please let me know if there are any problems. The TDBC API should be stable, now that three engines (ODBC, SQLite3, MySQL) are using it. Please, let's see some real testing, and some real attempts at additional drivers! -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-13 01:55:24
|
Larry W. Virden wrote: > Never mind. A bit later I discovered that the code I was building > wasn't today's snapshot but yesterdays. When I then built today's > snapshot, things went better. > > I apologize. OK, the change must have been something in Tcl's build system, because I didn't do anything to tdbc in the last few days. -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-13 01:23:19
|
Larry W. Virden wrote: > It looks to me as if the actual compilation of [tdbc's] C code isn't happening yet. > > Is this something that needs to be reported in a bug database > somewhere, or is this just reflecting that the process of integration > has begun but isn't complete yet? It's another new one to me. I routinely test Linux and Windows, but not Solaris; I'll have to find (or virtualize) a Solaris to see what's going on, or ask for help from Tcl maintainers that build there. -- 73 de ke9tv/2, Kevin |
From: Larry W. V. <lv...@gm...> - 2009-02-12 19:29:58
|
Never mind. A bit later I discovered that the code I was building wasn't today's snapshot but yesterdays. When I then built today's snapshot, things went better. I apologize. On Thu, Feb 12, 2009 at 9:12 AM, Larry W. Virden <lv...@gm...> wrote: > I just noticed that, as I was building the tcl 8.6 cvs head snapshot I > got this morning [...] -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.purl.org/net/lvirden/ http://www.xanga.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. |
From: Larry W. V. <lv...@gm...> - 2009-02-12 14:12:19
|
I just noticed that, as I was building the tcl 8.6 cvs head snapshot I got this morning from the activestate ftp site, that tcl's configure now configures and knows that the tdbc directory exists during the build step. gmake[1]: Entering directory `/vol/tclsrcsol/tcl86/tcl/unix/pkgs/tdbc' Creating pkgIndex.tcl gmake[1]: Leaving directory `/vol/tclsrcsol/tcl86/tcl/unix/pkgs/tdbc' However, when I ran the test suite, I see this: Tests began at Wed Feb 11 09:18:30 EST 2009 tdbc.test couldn't load file "../../pkgs/tdbc/libtdbc1.0b4.so": ld.so.1: tcltest: fatal: . ./../pkgs/tdbc/libtdbc1.0b4.so: open failed: No such file or directory tokenize.test couldn't load file "../../pkgs/tdbc/libtdbc1.0b4.so": ld.so.1: tcltest: fatal: . ./../pkgs/tdbc/libtdbc1.0b4.so: open failed: No such file or directory Then, later during install, I see: Installing package 'tdbc' gmake[1]: Entering directory `/vol/tclsrcsol/tcl86/tcl/unix/pkgs/tdbc' Install tdbc.tcl /projects/sprs_lwv/tcl86/lib/tdbc1.0b4/tdbc.tcl Install pkgIndex.tcl /projects/sprs_lwv/tcl86/lib/tdbc1.0b4 Install tdbcConfig.sh /projects/sprs_lwv/tcl86/lib/tdbc1.0b4 It looks to me as if the actual compilation of the C code isn't happening yet. Is this something that needs to be reported in a bug database somewhere, or is this just reflecting that the process of integration has begun but isn't complete yet? |
From: Patrick D. <pat...@ac...> - 2009-02-11 15:03:00
|
Yes, you caught me. I did source tdbcodbc.tcl. package require wasn't working I assumed because of the install problems so I decided to source to get around that. This will probably all be resolved when I get a clean install performed. Patrick Dunnigan Email: pat...@ac... Visit us at www.activecompliance.com This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email. -----Original Message----- From: Kevin Kenny [mailto:kk...@ny...] Sent: Tuesday, February 10, 2009 10:04 PM To: pat...@ac... Cc: tcl...@li... Subject: Re: [Tcl-tdbc] ODBC connection errors Patrick Dunnigan wrote: > I have tdbc odbc loaded, but I am sill trying to work out the exact > connection syntax. I am expecting to pass the DSN-less connection string > but getting an error as you can see below: > > % set conn_string "DRIVER=SQL > Server;SERVER=192.168.2.105,1433;DBQ=test;UID=test;PWD=test " > > DRIVER=SQL Server;SERVER=192.168.2.105,1433;DBQ=test;UID=test;PWD=test > > % tdbc::odbc::connection create db $conn_string > > unknown method "init": must be allrows, close, columns, destroy, eval, > foreach,prepare, preparecall, resultsets, statements, tables, > transaction, typemap, unknown, variable or varnamePatrick Dunnigan > > I know this is the correct connection string, I have tested it out with > other software. I am thinking that I am not using the > tdbc::odbc::connection command the right way for ODBC connections. Did you do [package require tdbc::odbc], or did you just do [source tdbcodbc.tcl]? You appear to be missing the parts of the driver that are written in C. I know that you had installation problems, so it's possible that your [package require] went awry. By the way, your connection string and your syntax both look quite plausible. -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-11 03:04:08
|
Patrick Dunnigan wrote: > 3. You mentioned man pages are there, but I don't see them in the Active > State 8.6b1 install or on the web. Can you point me to them? I still need to troubleshoot what's gone wrong with having the TDBC documents in ActiveTcl and on the www.tcl.tk web site, but I've bundled up the manual pages in HTML format over at http://preview.tinyurl.com/be7uj3 - download and unpack 'tdbc1.0b7-doc.ZIP' Onward to figuring out what's gone awry with the Windows binary installer - I'd have sworn I'd fixed that bug! -- 73 de ke9tv/2, Kevin |
From: Kevin K. <kk...@ny...> - 2009-02-11 03:02:15
|
Patrick Dunnigan wrote: > I have tdbc odbc loaded, but I am sill trying to work out the exact > connection syntax. I am expecting to pass the DSN-less connection string > but getting an error as you can see below: > > % set conn_string "DRIVER=SQL > Server;SERVER=192.168.2.105,1433;DBQ=test;UID=test;PWD=test " > > DRIVER=SQL Server;SERVER=192.168.2.105,1433;DBQ=test;UID=test;PWD=test > > % tdbc::odbc::connection create db $conn_string > > unknown method "init": must be allrows, close, columns, destroy, eval, > foreach,prepare, preparecall, resultsets, statements, tables, > transaction, typemap, unknown, variable or varnamePatrick Dunnigan > > I know this is the correct connection string, I have tested it out with > other software. I am thinking that I am not using the > tdbc::odbc::connection command the right way for ODBC connections. Did you do [package require tdbc::odbc], or did you just do [source tdbcodbc.tcl]? You appear to be missing the parts of the driver that are written in C. I know that you had installation problems, so it's possible that your [package require] went awry. By the way, your connection string and your syntax both look quite plausible. -- 73 de ke9tv/2, Kevin |