[sqlite] Why "TRUNCATE TABLE" can't empty a table?
Following is my program: rc = sqlite3_exec(db, "TRUNCATE TABLE students;", NULL, NULL, &errMsg); but this sentence can success and return 1. Help~ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Why "TRUNCATE TABLE" can't empty a table?
On 08/14/2012 02:04 PM, daedae11 wrote: Following is my program: rc = sqlite3_exec(db, "TRUNCATE TABLE students;", NULL, NULL, &errMsg); DELETE FROM students; ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Building System.Data.SQLite
I was referencing C:\Program Files (x86)\System.Data.SQLite\2010\bin\System.Data.SQLite.dll is this was the one shown in the VS2010->->Add Reference->.NET section. I removed that reference and added a reference to C:\Program Files\System.Data.SQLite\2010\bin\System.Data.SQLite.dll instead. This worked as intended. Why is VS2010 only showing x86 references in .NET section of the Add Reference browser? My project is targetted "Any CPU", but I have tried x86 and x64 but neither worked with C:\Program Files (x86)\System.Data.SQLite\2010\bin\System.Data.SQLite.dll Anyway, it works and that is great. :) The old-school dll hell is easier to make sense of than the .NET dll hell. :-P -- Bernhard -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Joe Mistachkin Sent: 14. august 2012 00:19 To: 'General Discussion of SQLite Database' Subject: Re: [sqlite] Building System.Data.SQLite Bernhard Mogens Ege wrote: > > This doesn't appear to build everything needed as when I install the bundles > (x86 and x64), nothing is added to the global assembly cache in > C:\windows\assembly\ (did ask the installer to add to the GAC), making every > binary using System.Data.SQLite fail. The files are put into > C:\Program Files\.. as expected, though, but binaries do not know to look there. > Installing the System.Data.SQLite DLLs in the GAC is not normally recommended. Instead, they should probably be installed along side the application binaries (i.e. "app-local"). Setting a reference to the managed (or mixed-mode) assembly for System.Data.SQLite is normally all that is required to make the applications work as the DLL should then automatically be copied to the build output directory. If you have Visual Studio 2010, then you may want to look into using the official NuGet package for System.Data.SQLite, seen here: http://nuget.org/packages/System.Data.SQLite > > Also, the Designer adding for VS2010 isn't working properly as it > isn't possible to enter a path with a space in it (Illegal sharacters > in path.), making the VS addin a no-go. This is a quite annoying error > which makes it very difficult for me to modify my sqlite models; close > all VS2010, remove sqlite 1.0.82.0, possibly reboot, install 1.0.81.0 > incl. VS plugin, start > vs2010 and load my project, modify my sqlite model, close vs2010, uninstall > 1.0.81.0, possibly reboot, install 1.0.82.0, start and load my > project, test, continue programming. Maybe I can just use the > Designer.dll from > 1.0.81.0 with the rest from 1.0.82.0? That would be worth a try. > The designer components are a bit tricky to get working right, even in the best of circumstances. They actually *do* require the setup package be run in order to operate properly. Also, since Visual Studio is always a 32-bit native application, that setup package is the one that must be used. Here is the direct link to the correct package: http://system.data.sqlite.org/downloads/1.0.81.0/sqlite-netFx40-setup-bundle -x86-2010-1.0.81.0.exe -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Building System.Data.SQLite
Regarding the Designer and the must-not-use-space-in-filenames problem, I
ended up using the 8.3 filename of the folder having the space in it.
("Visual Studio 2010" -> "Visual~1")
The Designer source for 1.0.81.0 seems to be the same as 1.0.82.0 so both
would error on this space. The difference most likely is in
System.Data.SQLite itself (SQLiteConnection.cs) but while I have looked at
the source, I didn't find the actual error.
I'll use my workaround for the time being. This is just the GUI in VS2010
acting up.
When building my own connection string in my project, I can use spaces in
filenames without problems.
--
Bernhard
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Joe Mistachkin
Sent: 14. august 2012 00:19
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Building System.Data.SQLite
Bernhard Mogens Ege wrote:
>
> This doesn't appear to build everything needed as when I install the
bundles
> (x86 and x64), nothing is added to the global assembly cache in
> C:\windows\assembly\ (did ask the installer to add to the GAC), making
every
> binary using System.Data.SQLite fail. The files are put into
> C:\Program Files\.. as expected, though, but binaries do not know to look
there.
>
Installing the System.Data.SQLite DLLs in the GAC is not normally
recommended.
Instead, they should probably be installed along side the application
binaries (i.e. "app-local"). Setting a reference to the managed (or
mixed-mode) assembly for System.Data.SQLite is normally all that is required
to make the applications work as the DLL should then automatically be copied
to the build output directory.
If you have Visual Studio 2010, then you may want to look into using the
official NuGet package for System.Data.SQLite, seen here:
http://nuget.org/packages/System.Data.SQLite
>
> Also, the Designer adding for VS2010 isn't working properly as it
> isn't possible to enter a path with a space in it (Illegal sharacters
> in path.), making the VS addin a no-go. This is a quite annoying error
> which makes it very difficult for me to modify my sqlite models; close
> all VS2010, remove sqlite 1.0.82.0, possibly reboot, install 1.0.81.0
> incl. VS plugin, start
> vs2010 and load my project, modify my sqlite model, close vs2010,
uninstall
> 1.0.81.0, possibly reboot, install 1.0.82.0, start and load my
> project, test, continue programming. Maybe I can just use the
> Designer.dll from
> 1.0.81.0 with the rest from 1.0.82.0? That would be worth a try.
>
The designer components are a bit tricky to get working right, even in the
best of circumstances. They actually *do* require the setup package be run
in order to operate properly. Also, since Visual Studio is always a 32-bit
native application, that setup package is the one that must be used. Here
is the direct link to the correct package:
http://system.data.sqlite.org/downloads/1.0.81.0/sqlite-netFx40-setup-bundle
-x86-2010-1.0.81.0.exe
--
Joe Mistachkin
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any plans to provide the sqlite3RunParser in the API
On 08/13/2012 05:51 PM, Jay A. Kreibich wrote: On Mon, Aug 13, 2012 at 03:43:46PM +0200, Bishwa Shrestha scratched on the wall: Hi, I've recently started using sqlite3 c-library. I'm using the in-memory databases which are pretty fast since I'm loading data dynamically into sqlite3 from a different backend (had to do this as we wanted to provide an SQL interface to our users). If you want to provide an SQL interface to an existing data source, I would strongly recommend you look at Virtual Tables. They look and smell like normal tables, but all of their access and data generation is done via application level code. You can write a series of functions that essentially slip in between the SQL engine and the data access layer, and can redirect requests for table data to an external source. Virtual Tables can be read-write or read-only. Read-only tables are pretty fast to implement, while read-write tables would allow external applications to modify the backend (no idea if that is desirable or not in your case). Virtual Tables are an extremely powerful and often overlooked part of SQLite. You can do some pretty amazing and powerful things with them, as evident by the Full Text Search engine in SQLite, as well as the R-Trees extension, both of which are built on top of Virtual Tables. SQLite docs: http://www.sqlite.org/vtab.html http://www.sqlite.org/c3ref/create_module.html Virtual Tables are also covered fairly well in "Using SQLite": http://shop.oreilly.com/product/9780596521196.do -j Hi Jay, thank you for your suggestion. I am looking at sqlite3 virtual tables and am liking what I see :) . However, please note that this doesn't completely answer my original question. It would be nice if someone could respond in that regard. * Unknown - detected * English * English ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any plans to provide the sqlite3RunParser in the API
On 08/14/2012 04:05 PM, Bishwa Shrestha wrote: On 08/13/2012 05:51 PM, Jay A. Kreibich wrote: On Mon, Aug 13, 2012 at 03:43:46PM +0200, Bishwa Shrestha scratched on the wall: Hi, I've recently started using sqlite3 c-library. I'm using the in-memory databases which are pretty fast since I'm loading data dynamically into sqlite3 from a different backend (had to do this as we wanted to provide an SQL interface to our users). If you want to provide an SQL interface to an existing data source, I would strongly recommend you look at Virtual Tables. They look and smell like normal tables, but all of their access and data generation is done via application level code. You can write a series of functions that essentially slip in between the SQL engine and the data access layer, and can redirect requests for table data to an external source. Virtual Tables can be read-write or read-only. Read-only tables are pretty fast to implement, while read-write tables would allow external applications to modify the backend (no idea if that is desirable or not in your case). Virtual Tables are an extremely powerful and often overlooked part of SQLite. You can do some pretty amazing and powerful things with them, as evident by the Full Text Search engine in SQLite, as well as the R-Trees extension, both of which are built on top of Virtual Tables. SQLite docs: http://www.sqlite.org/vtab.html http://www.sqlite.org/c3ref/create_module.html Virtual Tables are also covered fairly well in "Using SQLite": http://shop.oreilly.com/product/9780596521196.do -j Hi Jay, thank you for your suggestion. I am looking at sqlite3 virtual tables and am liking what I see :) . However, please note that this doesn't completely answer my original question. It would be nice if someone could respond in that regard. There are no plans to make sqlite3RunParser() part of the API. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
