On 1 Sep 2017, at 9:50pm, Simon Slavin wrote:
> you appear to be trying to execute a command with the database name in,
> something like
>
>> "F:\\Temp\\test_database.jdb "VACUUM"
I’ve just realised what’s going on. OP has confused the sqlite3 shell tool
with what it’s like to use the SQLi
> On Sep 1, 2017, at 1:47 PM, Papa wrote:
>
> Yes, right after opening the database, I want o perform a vacuuming so that
> the new tables can be created, writing and/or read.
I don't know how to put this politely, but you seem to be making things up out
of thin air. There's nothing anywhere
And look at the oh so usefully provided return code from the prepare call ...
there is NO POINT WHATSOEVER in looking at the statement pointer if the return
code does not indicate that the prepare prepared anything. So if the
returncode is ANYTHING OTHER THAN SQLITE_OK then you should be expec
On 1 Sep 2017, at 9:47pm, Papa wrote:
> Yes, right after opening the database, I want o perform a vacuuming so that
> the new tables can be created, writing and/or read.
You do not need to execute VACUUM to use new tables. In fact the command will
cause a long delay for no useful result, si
On 1 Sep 2017, at 9:24pm, Papa wrote:
> database_name = "F:\\Temp\\test_database.jdb";
and later
>sql_statement_request = database_name + L" \"VACUUM; \" ";
>// Compiled the SQL statement into a byte-code
>rc = sqlite3_prepare_v2(db,
>sql_statement_request.data()
Yes, right after opening the database, I want o perform a vacuuming so
that the new tables can be created, writing and/or read.
On 2017-09-01 4:31 PM, Igor Korot wrote:
Hi,
What are you trying to achieve?
Are you trying to perform a "VACUUM" command on the data base?
Thank you.
On Sep 1, 20
Hi,
What are you trying to achieve?
Are you trying to perform a "VACUUM" command on the data base?
Thank you.
On Sep 1, 2017 2:23 PM, "Papa" wrote:
In this snip, I'd like to show a brief description of what the class member
function should do, in order to ask you if the SQL statement has been
Thanks for your suggestion Jens, I tried it and this is what they report.
---
DEBUGING
---
sqlite3_extended_errcode == 1
sqlite3_errcode == 1
sqlite3_errmsg == near "F": syntax error
---
OK
---
Wha
Thank you all for your feedback. I now have a lot more to digest. I
will investigate the attach command. I am concerned about keeping all
of my company's data in 1 file, as if something happened to that file, I
would have data entry, programming, etc. to on all systems since the
last backup,
> On Sep 1, 2017, at 11:23 AM, Papa wrote:
>
> I get an error indicating that binary_sql_statement evaluates to NULL.
Most often that means there's a syntax error in the SQL statement.
You should call sqlite3_errcode() to get the error code, and sqlite3_errmsg()
to get an error message.
—Jen
Other notes in addition to the previous responses.
File size will never go down without some sort of vacuum operation. Basically
since you can only truncate files, and not snip out sections in the middle. If
you delete from the front of a large file, in order to shrink it you'd have to
re-write
In this snip, I'd like to show a brief description of what the class
member function should do, in order to ask you if the SQL statement has
been properly prepared.
sqlite3* db; //!< Data Base
std::string database_name; //!< The name of the database
std::string sql_statement_request;
Thanks everyone for your input.
I am sorry, the error was cause by human error, i.e. my mistake :-P
On 2017-08-31 9:43 PM, Papa wrote:
This is not a SQLite3 problem, it shows to be a MinGW
(mingw32/7.1.0/...) -> Target: 64bit, however, I just wanted to know
if anyone here has experience the s
On 2017/09/01 6:53 PM, Jacky Lam wrote:
What I am understood from the answer is explicit code must be used during
creating db, for example, auto_vacuum=FULL.
If no, the file size will not reduce even deleting a number of records and
this is normal.
Yes. If you create the database and run the S
Ok, they are two individual ways to vacuum the db file size. Thanks.
On Sat, Sep 2, 2017 at 1:17 AM, Darko Volaric wrote:
> Maybe you misunderstood that sentence: "auto_vacuum=FULL" mode will
> reduce the file size but so will a "VACUUM" command, independent of the
> auto_vacuum setting. It mak
Maybe you misunderstood that sentence: "auto_vacuum=FULL" mode will reduce the
file size but so will a "VACUUM" command, independent of the auto_vacuum
setting. It makes that crystal clear by detailing how it works later on that
page:
> The VACUUM command works by copying the contents of the
What I am understood from the answer is explicit code must be used during
creating db, for example, auto_vacuum=FULL.
If no, the file size will not reduce even deleting a number of records and
this is normal.
On Sat, Sep 2, 2017 at 12:47 AM, Stephen Chrzanowski
wrote:
> You'll want to vacuum th
err.. Clarification... It can be set to automatically vacuum the database
on connection close when setting a particular pragma.
On Fri, Sep 1, 2017 at 12:47 PM, Stephen Chrzanowski
wrote:
> You'll want to vacuum the database.
>
> https://sqlite.org/lang_vacuum.html
>
> Deleting records from a S
You'll want to vacuum the database.
https://sqlite.org/lang_vacuum.html
Deleting records from a SQLite database only changes the pages that already
exist within the file. It doesn't prune anything automatically. It can do
so, though, if you set the appropriate pragma.
On Fri, Sep 1, 2017 at 12
Hi All,
While using my own implemented file system, the db file size will only
expand and not prune even remove record from the db.
Could anyone advise me that what I am missing in order to pruning the db
size when removing a number of records?
Jacky
On Wed, Aug 9, 2017 at 11:02 AM, Simon Slavin
On Fri, Sep 1, 2017 at 9:08 AM, Olivier Mascia wrote:
>
> The (calling program) bug starts here above.
> sql_statement_request.data() is not guaranteed to be zero-terminated (and
> generally isn't).
>
FWIW, it is since std C++11, i.e. .data() and .c_str() are equivalent going
forward [1].
It was
> Le 1 sept. 2017 à 03:43, Papa a écrit :
>
> std::string sql_statement_request;
> ...
> rc = sqlite3_prepare_v2(db,
> sql_statement_request.data(),
> -1,
The (calling program) bug starts here above.
sql_statement_request.data() is not guaranteed to be zero-termin
22 matches
Mail list logo
