Then it's definitely different database files or indeed some really
weird network disk caching.

Pavel


On Tue, Jun 19, 2012 at 12:19 PM,  <chris_how...@mcafee.com> wrote:
> Good question. I thought the same, the issue persists across  not just an app 
> restart but a restart of the entire OS.
>
> Cheers
> Chris
>
> -----Original Message-----
> From: Pavel Ivanov [mailto:paiva...@gmail.com]
> Sent: Tuesday, June 19, 2012 12:17 PM
> To: Howell, Chris
> Cc: sqlite-users@sqlite.org
> Subject: Re: [sqlite] SQL Lite 2.8.6 Not deleting Enteries
>
> It seems to me you are using SQLite database in WAL-mode and when you delete 
> rows from SQLShell your app has some read-only transaction open (or it has 
> already started executing its SELECT statement that should return deleted 
> rows). Does the issue persist across app restarts?
>
> Pavel
>
> On Tue, Jun 19, 2012 at 11:38 AM,  <chris_how...@mcafee.com> wrote:
>>
>> -----Original Message-----
>> From: sqlite-users-boun...@sqlite.org
>> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Pavel Ivanov
>> Sent: Tuesday, June 19, 2012 11:27 AM
>> To: General Discussion of SQLite Database
>> Subject: Re: [sqlite] SQL Lite 2.8.6 Not deleting Enteries
>>
>>> 4.      Try to select against any of these tables and 0 results are 
>>> returned yet, the client db hasn't actually changed it's size.
>>
>> By default SQLite doesn't shrink database file size when deleting data, 
>> although it reuses this space later when you insert new data. If you want to 
>> shrink file size you need to use VACUUM or PRAGMA auto_vacuum.
>>
>> [CH] - Good to know Thanks
>>
>>
>>> 5.      When debugging the issue, the app still reports all entries via SQL 
>>> query that I, thought were deleted from within SqlShell.
>>
>> Did you issue COMMIT in your SqlShell? If you close database in SqlShell and 
>> then reopen again will it still report no rows in the database?
>>
>> [CH] - Yes if I close the SQLShell and re-open it still reports 0 rows.
>>
>>> When I place a debug Message box to display the messages selected from the 
>>> client db I see all the messages even though a select statement against the 
>>> tables returns 0 results.
>>
>> I wonder what did you mean to say here. If SELECT statement returns 0 rows 
>> you can't show any messages unless you get it from somewhere else.
>>
>> [CH] - What I meant to say is. As follows when debugging the application, I 
>> place a debug statement to show me the query and the results, when the 
>> client app. Executes it's statement there are valid results that are 
>> returned. I know it stands to reason that, logically the results must be 
>> coming from somewhere else if a select statement in the SQLShell reports 0 
>> results, but the same select stmt exec'd within the context of the app 
>> actually returns results. However how do then explain that when copying an 
>> empty database in place of the one being currently queried that both the app 
>> and the SQLShell report the same thing ?
>>
>>> I know I am accessing the same database, because if I copy a completely 
>>> empty database, to where the client db is. Then the app reports 0 records.
>>
>> And after doing that if you insert some rows from SqlShell will the app 
>> report any records? If not or if database reopening in SqlShell (which was 
>> suggested above) still results in different number of records in app and in 
>> SqlShell then you definitely use different database files.
>>
>> [CH] - Correct after doing that if I insert records via the SQLShell the app 
>> will report the records & the shell and app report the equal number of 
>> records.
>>
>>
>> Chris
>>
>>
>> Pavel
>>
>>
>> On Tue, Jun 19, 2012 at 11:09 AM,  <chris_how...@mcafee.com> wrote:
>>> I've got a bit of an interesting issue that I am hoping to get some help 
>>> on. The issue goes a little bit like this.
>>>
>>> Using Windows 8 64bit, Release Preview 8400. (Classic Mode)
>>>
>>> 1.      Our product is installed and requests data from the server. (Server 
>>> responds and populates a database on the client machine).
>>> 2.      Connect to the database on the client machine (Open the database 
>>> using SQLShell) can see the entries in the database, so I know the database 
>>> is being populated.
>>> 3.      Execute delete statements, on tables in SQLLIte Database.
>>> 4.      Try to select against any of these tables and 0 results are 
>>> returned yet, the client db hasn't actually changed it's size.
>>> 5.      When debugging the issue, the app still reports all entries via SQL 
>>> query that I, thought were deleted from within SqlShell.
>>>
>>> Essentially it's as if the messages are being flagged for deletion but not 
>>> actually getting deleted. When I place a debug Message box to display the 
>>> messages selected from the client db I see all the messages even though a 
>>> select statement against the tables returns 0 results.
>>>
>>> I know I am accessing the same database, because if I copy a completely 
>>> empty database, to where the client db is. Then the app reports 0 records.
>>>
>>> Any light someone could shed on this would be appreciated.
>>>
>>> Cheers,
>>> Chris
>>> _______________________________________________
>>> 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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to