This assumes that there is some kind of backing store that needs to be created
once (xCreate) but may be conncted to (xConnect) later.
CREATE VIRTUAL TABLE calls the xCreate function (and DROP TABLE will call
xDestroy), whereas queries will call the xConnect function. IIRC connecting to
an SQLi
Eric Kundl wrote:
>
> Using VS and SQLite (from NuGet pkg).
>
What version of Visual Studio and NuGet are you using?
>
> After the 'build' of the solution/project, the file
> System.Data.SQLite.dll.config is included in the bin\release folder.
>
I have not seen this behavior before. Are you
The documentation says that "The difference is that xConnect is called to
establish a new connection to an existing virtual table whereas xCreate is
called to create a new virtual table from scratch." But this leaves me
unclear on the circumstances where xConnect would be called (assuming I
have a
Using VS and SQLite (from NuGet pkg).
After the 'build' of the solution/project, the file
System.Data.SQLite.dll.config is included in the bin\release folder.
It has a note in it: do not copy this file to any of the build output
directories
How do I prevent it from appearing in the build out
To close this thread, it looks like this issue is about a sqlite bug
which was fixed last year:
http://www2.sqlite.org/cgi/src/info/7daa687340e47597
Applying the changes described there to the BDB/SQLite code fixed the
issue I was experiencing.
Thanks for all the help,
Minollo
Using VS and SQLite (from NuGet pkg).
After the 'build' of the solution/project I'm working on that uses SQLite,
the file System.Data.SQLite.dll.config is included in the bin\release
folder.
It has a note in it: do not copy this file to any of the build output
directories
How do I prevent it
On Wed, Jul 24, 2019 at 3:09 PM Hick Gunter wrote:
> With the current interface, the xBestIndex function has the possibility of
> returning "effort" and "result set size" separately, instead of just an
> aggregate "effort" (which was at the time documented to assume "result set
> size").
>
Thank
With the current interface, the xBestIndex function has the possibility of
returning "effort" and "result set size" separately, instead of just an
aggregate "effort" (which was at the time documented to assume "result set
size").
Since we have nearly no native tables here, the question of "rela
Thanks Keith and Charles; the Berkeley DB folks are looking into it, and
I forwarded them this information.
Minollo
Yes, that old version (from about 2 years ago) crashes (on Windows).
No, the current one does not crash and produces two output lines.
This is using your test SQL with the spelli
On Wed, Jul 24, 2019 at 10:45 AM Hick Gunter wrote:
> The speed of a virtual table depends on the backing store and software
> used to implement it.
>
[DD] Sure. virtual-tables can also access the disk and do expensive things.
[DD] I did say "example given" for my fast-pure-memory-no-decoding ca
The speed of a virtual table depends on the backing store and software used to
implement it.
We have virtual tables that reference CTree files as well as virtual tables
that reference memory sections here. The advantage is that the VT
implementation can adjust it's answers in the xBestIndex fun
On Wed, Jul 24, 2019 at 2:55 AM Justin Olbrantz
wrote:
> [...] my virtual table will be held completely in memory. What should I do
> with the
> estimatedCost value from xBestIndex? According to the documentation this
> should be an approximation of the number of disk accesses for the query,
> wh
12 matches
Mail list logo
