- Roadmap
-
Bugs
0
Fixed
Error importing .db file from 1.5.3 into 1.5.5
Reproduce (use two portable installations):
1. Create a new database in CN 1.5.3
2. Save one note with any content (I used "note" title, empty body)
3. Close CN
4. Start clean CN 1.5.5
5. File > Import > select .db from 1.5.3
6. Get error message:
If I simply copy that .db into CN 1.5.5 directory, it works.
Answer
0
Answer
Fixed
Alex Jenter 13 years ago
Fixed in 1.5.6
1.5.5p2 - importing small sample .db-s works now, but it crashes on importing my main notes .db (461 notes). I'm using this .db in CN 1.5.3 right now. It imports about 428 notes and then "The program has stopped working" popup appears with details:
Problem signature:
Problem Event Name:BEX
Application Name:CintaNotes.exe
Application Version:0.0.0.0
Application Timestamp:4f3726dd
Fault Module Name:CintaNotes.exe
Fault Module Version:0.0.0.0
Fault Module Timestamp:4f3726dd
Exception Offset:001116aa
Exception Code:c0000417
Exception Data:00000000
OS Version:6.1.7601.2.1.0.256.48
Locale ID:1033
Additional Information 1:967d
Additional Information 2:967deeb18b799d629b48b1d48044deaf
Additional Information 3:7519
Additional Information 4:7519631c357da284d70def3020eeb1f9
Observations:
* A nearly same sized .db file is produced before the crash.
* A tray icon is left after the crash unless I hover it - it then disappears.
* If I copy (not import) that .db file to the 1.5.5p2 folder and run CN, it runs OK and does something with that .db (size changes). If I then move it to another place (leaving 1.5.5p2 with no .db), and re-Import it, it imports all 461 notes quite quickly. This makes me think the problem logic is isolated in Import module.
* I also tried re-importing that file into a clean CN 1.5.3 - it works (no crash), and then produced .db file can be fed to CN 1.5.5p2 and it also works with no crash for all notes. That particular .db file has something corrupted inside, but crash isn't a healthy thing anyway.
Could you please download SQLiteSpy from here, load your suspicious .db file into it, run the following command:
PRAGMA user_version;
and tell me what it returns? Thanks!
PRAGMA user_version;
and tell me what it returns? Thanks!
It says 151, and also shows some error:
If I reimport that .db into a clean 1.5.3, version is also 151 and same error displayed. If then take it and import into a clean 1.5.5p2, version becomes 1550 but the same error is shown.
Thanks for the info! The "unknown tokenizer" error is not relevant - it appears because the DB is opened not from within CN.
Is there any chance you could send the crashing .db file to me? It would ease the debugging task enourmously! But of course you don't need to do that if you have any sensitive data in there.
Is there any chance you could send the crashing .db file to me? It would ease the debugging task enourmously! But of course you don't need to do that if you have any sensitive data in there.
Unfortunately it has some data I would like not to disclose.
Is there any task I could do to help catching the crash? (running debug build/tracing session/capturing memory dump)
Maybe you could erase this sensitive data using SQLiteSpy? I tend to think that the structure of the DB is to blame here.
I've found a way to reproduce it. Seems only 1.5.3 is capable of "producing" .dbs that crash 1.5.5+.
1. Make clean (no .db) portable CN 1.5.3 dir.
2. Start CN
3. Add first note. For example, title="1", no body
4. Add second note. Title="2", no body
5. Delete first note, close CN
6. Try importing produced .db in 1.5.5 and 1.5.6p2-p3.
Result: 1.5.5 fails without crash:
1.5.6p2 and 1.5.6p3 crash with "cintanotes.exe has stopped working" described earlier.
First it felt that the trouble was in NotesData_segdir and NotesData_segments tables, because they were different in failing (from 1.5.3) and not failing (1.5.5) .dbs. But when I minimized the input that causes a crash, these tables looked identically produced by 1.5.3 and 1.5.5, but importing the second one in 1.5.5+ doesn't crash it. The only difference I could find was user_version 151 for first one and 1550 for second one.
Huge thanks for this info! Thanks to your help I was able to locate and fix the bug.
Here's the fix: http://cintanotes.com/forum/download/file.php?id=190
Here's the fix: http://cintanotes.com/forum/download/file.php?id=190
By the way, in the progress of previous research I've noticed inconsistent date formats in NotesCache table:
Look at records 13-15. There are also some records in dd.MM.yyyy lower in the table. I have one guess - I carry portable CN on my USB drive and have edited it at least on 3 various machines. One has yyyy.MM.dd, another M/d/yyyy tt, and the third one has dd.MM.yyyy.
+1
Thanks for noticing this. Yes, this is because of different date format settings on different PCs. The cached values are used for time-based search.The problem will be only that the time search won't find all the notes.
But since time based search is textual and will go away anyway (text-based matching will be replaced with date-based matching), and these columns will be removed from the NoteCache table, I think there's no real need for fixing it right away.
But since time based search is textual and will go away anyway (text-based matching will be replaced with date-based matching), and these columns will be removed from the NoteCache table, I think there's no real need for fixing it right away.
Customer support service by UserEcho
