[sqlite] tclsqlite3 db function exports not visible on other connections. Why not?
Taking DRH's remarks about learning tclsqlite for the efficient coding to heart, I discovered a big problem. Here is the simplest example from the docs and DRH presentation: TCLSH % db function myhex {format 0x%X}; % db eval {select myhex(10);} x {parray x}; x(*) = myhex(10) x(myhex(10)) = 0xA Now, on the same database with simultaneous connection eg: shell, odbc, etc: sqlite> select myhex(10); Run Time: real 0.000 user 0.00 sys 0.00 Error: no such function: myhex - Did I missing something in the docs? Is there a trick/pragma to make this work? Tclsqlite is extremely efficiently for extending sqlite but this facility is generally useless if the whole application must be ported to (or at least all db queries funneled through) TCLSH to use those easy to build extensions. What if the outer application can't be ported to TCL? Is there another way, like preloading TCL code on the ODBC connection? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?
On 2017/03/19 11:05 AM, petern wrote: Taking DRH's remarks about learning tclsqlite for the efficient coding to heart, I discovered a big problem. Here is the simplest example from the docs and DRH presentation: TCLSH % db function myhex {format 0x%X}; % db eval {select myhex(10);} x {parray x}; x(*) = myhex(10) x(myhex(10)) = 0xA Now, on the same database with simultaneous connection eg: shell, odbc, etc: sqlite> select myhex(10); Run Time: real 0.000 user 0.00 sys 0.00 Error: no such function: myhex - Did I missing something in the docs? Is there a trick/pragma to make this work? Tclsqlite is extremely efficiently for extending sqlite but this facility is generally useless if the whole application must be ported to (or at least all db queries funneled through) TCLSH to use those easy to build extensions. What if the outer application can't be ported to TCL? Adding a custom function (Whether done in your code using the API or using TCL or whatever) makes that function belong to the connection, a function cannot belong to the database or persist outside of the creating connection. tclsqlite is a great way to code for examples or reproducible bugs or even full DB maintenance scripts - but you can't use it together with your normal program code from a different connection. I'm not sure if there exist any way (or hack) to achieve this, maybe someone else knows, but what you tried won't work. This is not a tclsqlite problem, if you open a connection from one of your programs, add to it a custom function, and then open another connection to the same DB from one of your other programs, the custom function will of course NOT exist for the second connection - it's strictly a per-connection thing, and the second connection must register its own custom function. There exist some add-ons for sqlite which introduce ways of creating custom functions INSIDE the SQL via a query. Not sure if this will solve your problem, if so ask again (or google) for links to them. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?
You can use sqlite3_auto_extension for this. On 19 March 2017 at 11:35, R Smith wrote: > > On 2017/03/19 11:05 AM, petern wrote: >> >> Taking DRH's remarks about learning tclsqlite for the efficient coding to >> heart, I discovered a big problem. >> >> Here is the simplest example from the docs and DRH presentation: >> >> TCLSH >> % db function myhex {format 0x%X}; >> % db eval {select myhex(10);} x {parray x}; >> x(*) = myhex(10) >> x(myhex(10)) = 0xA >> >> Now, on the same database with simultaneous connection eg: shell, odbc, >> etc: >> >> sqlite> select myhex(10); >> Run Time: real 0.000 user 0.00 sys 0.00 >> Error: no such function: myhex >> >> >> - >> Did I missing something in the docs? >> Is there a trick/pragma to make this work? >> >> Tclsqlite is extremely efficiently for extending sqlite but this facility >> is generally useless if the whole application must be ported to (or at >> least all db queries funneled through) TCLSH to use those easy to build >> extensions. What if the outer application can't be ported to TCL? > > > Adding a custom function (Whether done in your code using the API or using > TCL or whatever) makes that function belong to the connection, a function > cannot belong to the database or persist outside of the creating connection. > tclsqlite is a great way to code for examples or reproducible bugs or even > full DB maintenance scripts - but you can't use it together with your normal > program code from a different connection. I'm not sure if there exist any > way (or hack) to achieve this, maybe someone else knows, but what you tried > won't work. > > This is not a tclsqlite problem, if you open a connection from one of your > programs, add to it a custom function, and then open another connection to > the same DB from one of your other programs, the custom function will of > course NOT exist for the second connection - it's strictly a per-connection > thing, and the second connection must register its own custom function. > > There exist some add-ons for sqlite which introduce ways of creating custom > functions INSIDE the SQL via a query. Not sure if this will solve your > problem, if so ask again (or google) for links to them. > > > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Yet Another Why Doesn't Sqlite Use My Index question ...
What is the average size of the text in the direction field? and what page size have you set for the database? If the size of a record is such that only a small handful fit into a page, or worse each record overflows (and your select includes the direction field) then this could impact performance. Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On 18 March 2017 at 05:48, Rob Willett wrote: > We've just implemented a covering index for the last step (is it really?) > in our quest to get the query execution time down. > > To summarise we have gone from 32 mins to 16 mins by updating an index so > it doesn't use collate, we took another six minutes off by removing extra > fields in the select we didn't need. > > We have just created a new index which 'covers' all the fields we use in > the select, this means (and I paraphrase) that we use the index to get all > the data and there is no need to read from the database. > > Well that was a bit of a surprise, the index creation took 45 mins, we ran > the program again and thought, rats, we've cocked it up, it only took 54 > secs, we got something wrong. So we checked it and checked again and we > hasn't got anything wrong. Our query has moved from 32 mins to 54 secs. > > We're quite happy with that performance increase. In fact we're delighted, > so thanks for all the help in getting us to this stage. > > We have kept copies of the query planner bytecode output if anybody is > interested. Gunter has had copies, but if anybody else would like them, > please ask. > > Many thanks again for all the help, > > Rob > > > On 17 Mar 2017, at 22:12, Rob Willett wrote: > > Dear all, >> >> We progress steadily forward. >> >> 1. We immediately halved our execution time by moving to an updated index >> that doesn't use COLLATE. Thats 32mins to 16mins. >> >> 2. We then shaved a further six minutes off the execution time by >> removing extraneous fields in the select statement, so instead of "select * >> ...", we identified which fields we used and directly selected those. So we >> are now down to 10 mins or 1/3 of when we started for, to be honest, >> virtually no extra work, merely being smarter, or rather you being smarter. >> >> 3. We have looked through all our indexes and can see that every index >> has a COLLATE against it, even if the column is an integer. We have raised >> a support call with Navicat. >> >> 4. The next step is to create a "covering index" to try and get the whole >> of the query into the index. However its 22:11 in London and I need to get >> home. >> >> Thanks very much for the help so far. Tomorrow is more tricky but I'll >> read up on covering indexes to see how to use them,. >> >> Rob >> >> On 17 Mar 2017, at 18:39, Simon Slavin wrote: >> >> On 17 Mar 2017, at 6:22pm, Rob Willett >>> wrote: >>> >>> 4. Work through returning just the columns we actually need from our queries. We have a recollection that if we can build an index with all the information necessary in it, we can do all the work in joins rather than paging out to disk. Is this what you are referring to? >>> >>> It works only where all the columns you need to read are in the same >>> table. The ideal form of a covering index is to have the columns listed in >>> this order: >>> >>> 1) columns needed for the WHERE clause >>> 2) columns needed for the ORDER BY clause which aren’t in (1) >>> 3) columns needed to be read which aren’t in (2) or (1) >>> >>> SQLite detects that all the information it needs for the SELECT is >>> available from the index, so it doesn’t bother to read the table at all. >>> This can lead to something like a doubling of speed. Of course, you >>> sacrifice filespace, and making changes to the table takes a little longer. >>> >>> 5. Sleep (not exactly sure when) and watch three international rugby games tomorrow. >>> >>> Sleep while waiting for indexes to be created and ANALYZE to work. May >>> you see skilled players, creative moves and dramatic play. >>> >>> Simon. >>> ___ >>> sqlite-users mailing list >>> sqlite-users@mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >> ___ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Yet Another Why Doesn't Sqlite Use My Index question ...
Oops - somehow misread the last message - 54 seconds down from 32 minutes - that's a result! Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On 19 March 2017 at 12:07, Paul Sanderson wrote: > What is the average size of the text in the direction field? and what page > size have you set for the database? If the size of a record is such that > only a small handful fit into a page, or worse each record overflows (and > your select includes the direction field) then this could impact > performance. > > Paul > www.sandersonforensics.com > skype: r3scue193 > twitter: @sandersonforens > Tel +44 (0)1326 572786 <+44%201326%20572786> > http://sandersonforensics.com/forum/content.php?195-SQLite- > Forensic-Toolkit -Forensic Toolkit for SQLite > email from a work address for a fully functional demo licence > > On 18 March 2017 at 05:48, Rob Willett > wrote: > >> We've just implemented a covering index for the last step (is it really?) >> in our quest to get the query execution time down. >> >> To summarise we have gone from 32 mins to 16 mins by updating an index so >> it doesn't use collate, we took another six minutes off by removing extra >> fields in the select we didn't need. >> >> We have just created a new index which 'covers' all the fields we use in >> the select, this means (and I paraphrase) that we use the index to get all >> the data and there is no need to read from the database. >> >> Well that was a bit of a surprise, the index creation took 45 mins, we >> ran the program again and thought, rats, we've cocked it up, it only took >> 54 secs, we got something wrong. So we checked it and checked again and we >> hasn't got anything wrong. Our query has moved from 32 mins to 54 secs. >> >> We're quite happy with that performance increase. In fact we're >> delighted, so thanks for all the help in getting us to this stage. >> >> We have kept copies of the query planner bytecode output if anybody is >> interested. Gunter has had copies, but if anybody else would like them, >> please ask. >> >> Many thanks again for all the help, >> >> Rob >> >> >> On 17 Mar 2017, at 22:12, Rob Willett wrote: >> >> Dear all, >>> >>> We progress steadily forward. >>> >>> 1. We immediately halved our execution time by moving to an updated >>> index that doesn't use COLLATE. Thats 32mins to 16mins. >>> >>> 2. We then shaved a further six minutes off the execution time by >>> removing extraneous fields in the select statement, so instead of "select * >>> ...", we identified which fields we used and directly selected those. So we >>> are now down to 10 mins or 1/3 of when we started for, to be honest, >>> virtually no extra work, merely being smarter, or rather you being smarter. >>> >>> 3. We have looked through all our indexes and can see that every index >>> has a COLLATE against it, even if the column is an integer. We have raised >>> a support call with Navicat. >>> >>> 4. The next step is to create a "covering index" to try and get the >>> whole of the query into the index. However its 22:11 in London and I need >>> to get home. >>> >>> Thanks very much for the help so far. Tomorrow is more tricky but I'll >>> read up on covering indexes to see how to use them,. >>> >>> Rob >>> >>> On 17 Mar 2017, at 18:39, Simon Slavin wrote: >>> >>> On 17 Mar 2017, at 6:22pm, Rob Willett wrote: 4. Work through returning just the columns we actually need from our > queries. We have a recollection that if we can build an index with all the > information necessary in it, we can do all the work in joins rather than > paging out to disk. Is this what you are referring to? > It works only where all the columns you need to read are in the same table. The ideal form of a covering index is to have the columns listed in this order: 1) columns needed for the WHERE clause 2) columns needed for the ORDER BY clause which aren’t in (1) 3) columns needed to be read which aren’t in (2) or (1) SQLite detects that all the information it needs for the SELECT is available from the index, so it doesn’t bother to read the table at all. This can lead to something like a doubling of speed. Of course, you sacrifice filespace, and making changes to the table takes a little longer. 5. Sleep (not exactly sure when) and watch three international rugby > games tomorrow. > Sleep while waiting for indexes to be created and ANALYZE to work. May you see skilled players, creative moves and dramatic play. Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> __
Re: [sqlite] sqlite with Java
> > Why don't you provide an up-to-date version? this lib seems dead when we > look at the website, also why don't you put the sources on git it would be > easier to contribute or raise a bug if any... > I tried to compile the latest version of sqlite 3.17 with the latest sources of sqlitejava (http://www.ch-werner.de/javasqlite) with VS2015 Express Edition I downloaded the latest jdk-8u121. I have the following error: SQLite\JDBCDriver.java:9: error: JDBCDriver is not abstract and does not override abstract method getParentLogger() in Driver ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite with Java
On Sun, Mar 19, 2017 at 4:57 PM, Sylvain Pointeau < sylvain.point...@gmail.com> wrote: > Why don't you provide an up-to-date version? this lib seems dead when we >> look at the website, also why don't you put the sources on git it would be >> easier to contribute or raise a bug if any... >> > > I tried to compile the latest version of sqlite 3.17 with the latest > sources of sqlitejava (http://www.ch-werner.de/javasqlite) with VS2015 > Express Edition > I downloaded the latest jdk-8u121. > > I have the following error: SQLite\JDBCDriver.java:9: error: JDBCDriver is > not abstract and does not override abstract method getParentLogger() in > Driver > I just tried with jdk-6u45-x86: SQLite\JDBC2x\JDBCConnection.java:17: SQLite.JDBC2x.JDBCConnection is not abstract and does not override abstract method createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection public class JDBCConnection ^ .\SQLite\JDBC2x\JDBCDatabaseMetaData.java:10: SQLite.JDBC2x.JDBCDatabaseMetaData is not abstract and does not override abstract method getFunctionColumns(java.lang.String,java.lang.String,java.lang.String,java.lang.String) in java.sql.DatabaseMetaData public class JDBCDatabaseMetaData implements DatabaseMetaData { ^ .\SQLite\JDBC2x\JDBCResultSet.java:12: SQLite.JDBC2x.JDBCResultSet is not abstract and does not override abstract method updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet public class JDBCResultSet implements java.sql.ResultSet { ^ .\SQLite\JDBC2x\JDBCStatement.java:6: SQLite.JDBC2x.JDBCStatement is not abstract and does not override abstract method isPoolable() in java.sql.Statement public class JDBCStatement implements java.sql.Statement { ^ .\SQLite\JDBC2x\JDBCResultSetMetaData.java:5: SQLite.JDBC2x.JDBCResultSetMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class) in java.sql.Wrapper public class JDBCResultSetMetaData implements java.sql.ResultSetMetaData { ^ .\SQLite\JDBC2x\JDBCPreparedStatement.java:17: SQLite.JDBC2x.JDBCPreparedStatement is not abstract and does not override abstract method setNClob(int,java.io.Reader) in java.sql.PreparedStatement public class JDBCPreparedStatement extends JDBCStatement ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite with Java
On Sun, Mar 19, 2017 at 5:38 PM, Sylvain Pointeau < sylvain.point...@gmail.com> wrote: > On Sun, Mar 19, 2017 at 4:57 PM, Sylvain Pointeau < > sylvain.point...@gmail.com> wrote: > >> Why don't you provide an up-to-date version? this lib seems dead when we >>> look at the website, also why don't you put the sources on git it would be >>> easier to contribute or raise a bug if any... >>> >> >> I tried to compile the latest version of sqlite 3.17 with the latest >> sources of sqlitejava (http://www.ch-werner.de/javasqlite) with VS2015 >> Express Edition >> I downloaded the latest jdk-8u121. >> >> I have the following error: SQLite\JDBCDriver.java:9: error: JDBCDriver >> is not abstract and does not override abstract method getParentLogger() in >> Driver >> > > I just tried with jdk-6u45-x86: > > SQLite\JDBC2x\JDBCConnection.java:17: SQLite.JDBC2x.JDBCConnection is not > abstract and does not override abstract method > createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection > public class JDBCConnection >^ > .\SQLite\JDBC2x\JDBCDatabaseMetaData.java:10: > SQLite.JDBC2x.JDBCDatabaseMetaData > is not abstract and does not override abstract method > getFunctionColumns(java.lang.String,java.lang.String,java.lang.String,java.lang.String) > in java.sql.DatabaseMetaData > public class JDBCDatabaseMetaData implements DatabaseMetaData { >^ > it works with jdk-1_5_0_22 Please could we move this library to compile with the newest JDK and VS2015 without error and warning? I am ready to help for windows. Best regards, Sylvain ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite with Java
On 03/19/2017 05:38 PM, Sylvain Pointeau wrote: On Sun, Mar 19, 2017 at 4:57 PM, Sylvain Pointeau < sylvain.point...@gmail.com> wrote: Why don't you provide an up-to-date version? this lib seems dead when we look at the website, also why don't you put the sources on git it would be easier to contribute or raise a bug if any... I tried to compile the latest version of sqlite 3.17 with the latest sources of sqlitejava (http://www.ch-werner.de/javasqlite) with VS2015 Express Edition I downloaded the latest jdk-8u121. I have the following error: SQLite\JDBCDriver.java:9: error: JDBCDriver is not abstract and does not override abstract method getParentLogger() in Driver I just tried with jdk-6u45-x86: IMO it is no good idea to discuss specific issues of an only indirectly SQLite related library on this mailing list. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Subject: Re: sqlite with Java
> From: Sylvain Pointeau > > Why don't you provide an up-to-date version? this lib seems dead when we > look at the website, also why don't you put the sources on git it would be > easier to contribute or raise a bug if any... > > -- I first supported SQLite in my project Ajqvue in 2010 and started out with Werner's library. At some point I moved on to the Github xerial sqlite-jdbc mainly for that reason, was being updated. I can think of no real reason other than that. Maybe in the documentation something about the Pure Java Mode. There should be no problem between the H2 -> SQlite, Ajqvue supports both, though H2 has the more convention database Data Types. There are some SQL statement that H2 supports and not SQLite. Been awhile since reviewed might not be so now. Data Type Conversions: https://github.com/danap/ajqvue/blob/master/src/com/dandymadeproductions/ajqvue/datasource/TypesInfoCache.java SQL Statements See: Table 1. http://ajqvue.com/docs/Manual/Ajqvue_Manual.html danap. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite with Java
> > > IMO it is no good idea to discuss specific issues of an only indirectly > SQLite related > library on this mailing list OK yes I agree, where can we discuss about it? > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite with Java
On 03/19/2017 06:38 PM, Sylvain Pointeau wrote: IMO it is no good idea to discuss specific issues of an only indirectly SQLite related library on this mailing list OK yes I agree, where can we discuss about it? C'mon, you apparently obtained the source code of this dead project, didn't you? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?
Yes. I am aware of https://www.sqlite.org/loadext.html And that's a good point. However, one might be under the impression that SQLite is a TCL extension from DRH's presentation here: http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2009/proceedings/sqlitetcl/tcl2009-sqlite.pdf In fact, according to the title of that presentation, SQLite is the most popular TCL extension in the world! Furthermore, if the TCL byte code engine is already linked to the SQLite binary, one would think user defined TCL byte code could be executed directly instead of having to statically link the TCL byte code engine again and again for each extension binary. Here are some questions that need answers. 1. If it does, how does SQLite build the binary version of TCL code of its implementation? 2. What is the recommended way of building a SQLite loadext compatible library.so file from .tcl files and current tclsqlite3.c source file? On Sun, Mar 19, 2017 at 4:44 AM, Daniel Kamil Kozar wrote: > You can use sqlite3_auto_extension for this. > > On 19 March 2017 at 11:35, R Smith wrote: > > > > On 2017/03/19 11:05 AM, petern wrote: > >> > >> Taking DRH's remarks about learning tclsqlite for the efficient coding > to > >> heart, I discovered a big problem. > >> > >> Here is the simplest example from the docs and DRH presentation: > >> > >> TCLSH > >> % db function myhex {format 0x%X}; > >> % db eval {select myhex(10);} x {parray x}; > >> x(*) = myhex(10) > >> x(myhex(10)) = 0xA > >> > >> Now, on the same database with simultaneous connection eg: shell, odbc, > >> etc: > >> > >> sqlite> select myhex(10); > >> Run Time: real 0.000 user 0.00 sys 0.00 > >> Error: no such function: myhex > >> > >> > >> > - > >> Did I missing something in the docs? > >> Is there a trick/pragma to make this work? > >> > >> Tclsqlite is extremely efficiently for extending sqlite but this > facility > >> is generally useless if the whole application must be ported to (or at > >> least all db queries funneled through) TCLSH to use those easy to build > >> extensions. What if the outer application can't be ported to TCL? > > > > > > Adding a custom function (Whether done in your code using the API or > using > > TCL or whatever) makes that function belong to the connection, a function > > cannot belong to the database or persist outside of the creating > connection. > > tclsqlite is a great way to code for examples or reproducible bugs or > even > > full DB maintenance scripts - but you can't use it together with your > normal > > program code from a different connection. I'm not sure if there exist any > > way (or hack) to achieve this, maybe someone else knows, but what you > tried > > won't work. > > > > This is not a tclsqlite problem, if you open a connection from one of > your > > programs, add to it a custom function, and then open another connection > to > > the same DB from one of your other programs, the custom function will of > > course NOT exist for the second connection - it's strictly a > per-connection > > thing, and the second connection must register its own custom function. > > > > There exist some add-ons for sqlite which introduce ways of creating > custom > > functions INSIDE the SQL via a query. Not sure if this will solve your > > problem, if so ask again (or google) for links to them. > > > > > > > > ___ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?
On 3/19/17, petern wrote: > > In fact, according to the title of that presentation, SQLite is the most > popular TCL extension in the world! > > Furthermore, if the TCL byte code engine is already linked to the SQLite > binary, one would think user defined TCL byte code could be executed > directly instead of having to statically link the TCL byte code engine > again and again for each extension binary. Being a TCL extension does not imply that the TCL byte code engine is already linked in. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite with Java
> OK yes I agree, where can we discuss about it? > > For information, we continued this discussion privately. I succeed to build this library and I will use it in my project. Additionally I would be glad contribute if Christian needs my help. Furthermore, I will assess my need to have SSE, and if yes, I will buy it and integrate it (quite easily). I will also blog on how to compile it and how to use it, sooner or later, it might help other people having the same need. Best regards, Sylvain ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?
You wouldn't happen to have a TCL script you can share which approximates the SQLite interactive shell multiline input and .exit command to return to tclsh? Dot exit would be the only mandatory dot command needed. On Sun, Mar 19, 2017 at 12:28 PM, Richard Hipp wrote: > On 3/19/17, petern wrote: > > > > In fact, according to the title of that presentation, SQLite is the most > > popular TCL extension in the world! > > > > Furthermore, if the TCL byte code engine is already linked to the SQLite > > binary, one would think user defined TCL byte code could be executed > > directly instead of having to statically link the TCL byte code engine > > again and again for each extension binary. > > Being a TCL extension does not imply that the TCL byte code engine is > already linked in. > > -- > D. Richard Hipp > d...@sqlite.org > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users