Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?

[petern]

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

Re: [sqlite] sqlite with Java

[Sylvain Pointeau]

> 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?

[Richard Hipp]

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] tclsqlite3 db function exports not visible on other connections. Why not?

[petern]

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] sqlite with Java

[Christian Werner]

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] sqlite with Java

[Sylvain Pointeau]

>
>
> 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

[sqlite] Subject: Re: sqlite with Java

[dmp]

> 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

[Christian Werner]

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

Re: [sqlite] sqlite with Java

[Sylvain Pointeau]

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

[Sylvain Pointeau]

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

[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 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] Yet Another Why Doesn't Sqlite Use My Index question ...

[Paul Sanderson]

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
 

Re: [sqlite] Yet Another Why Doesn't Sqlite Use My Index question ...

[Paul Sanderson]

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

Re: [sqlite] tclsqlite3 db function exports not visible on other connections. Why not?

[Daniel Kamil Kozar]

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] tclsqlite3 db function exports not visible on other connections. Why not?

[R Smith]

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] tclsqlite3 db function exports not visible on other connections. Why not?

[petern]

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