View Single Post
  #12  
Old 06-19-2022, 02:50 AM
Spliff Spliff is offline
Registered User
 
Join Date: 04-07-2021
Posts: 192
The described problem does not derive from sqlite3.exe, it would probably be UR which does change something in its UR files which causes the problem.

In Navicat, I now also get, for every one of my UR files (all of them renamed to .db, and with signature changed to
SQLite format 3
(15 chars changed, and verified)
"14 - Unable to open database file"

whilst these files open normally in UR.

As said, my "normal" UR files, with .urd suffix and with UR signature, opened correctly in Navicat, after me having renamed them and changed their signature, and now, where I use alleged "native" SQLite files in UR, they don't open anymore in SQLite front-ends incl. sqlite3.exe.

Since the only difference to "before" I can remember of, is the suffix renaming - after your last hint, i had renamed all my UR files from .urd to .db -, whilst the signature change, for most of my about 30 UR files had already been done (as said, I had run a 010Editor script to "change" the (already changed) signature again and again, wrongly assuming that UR had changed it back, each time, to its UR signature):

When UR opens, or saves, UR databases with .db suffix, does it change anything within the file then, which is does not change when it opens / saves the same file with .urd suffix?

I'm at a complete loss here.

The problem is not caused by my earlier opening the files in question in some front-end, it systematically affects all my UR files, even when, except for the signature change, I only opened them in UR.

As well as UR, Systools SQLite Database Recovery opens the files normally.

What parts of the binary should I check for possible errors, please?


The described problem does not derive from sqlite3.exe, it would probably be UR which does change something in its UR files which causes the problem.

In Navicat, I now also get, for every one of my UR files (all of them renamed to .db, and with signature changed to
SQLite format 3
(15 chars changed, and verified)
"14 - Unable to open database file"

whilst these files open normally in UR.

As said, my "normal" UR files, with .urd suffix and with UR signature, opened correctly in Navicat, after me having renamed them and changed their signature, and now, where I use alleged "native" SQLite files in UR, they don't open anymore in SQLite front-ends incl. sqlite3.exe.

Since the only difference to "before" I can remember of, is the suffix renaming - after your last hint, i had renamed all my UR files from .urd to .db -, whilst the signature change, for most of my about 30 UR files had already been done (as said, I had run a 010Editor script to "change" the (already changed) signature again and again, wrongly assuming that UR had changed it back, each time, to its UR signature):

When UR opens, or saves, UR databases with .db suffix, does it change anything within the file then, which is does not change when it opens / saves the same file with .urd suffix?

I'm at a complete loss here.

The problem is not caused by my earlier opening the files in question in some front-end, it systematically affects all my UR files, even when, except for the signature change, I only opened them in UR.

As well as UR, Systools SQLite Database Recovery opens the files normally.

What parts of the binary should I check for possible errors, please?


EDIT:

Might it be that UR files, with suffix .db or db3 (I tried both), and with generic SQLite3 signature, might not be compliant to newest SQLite3 format anymore?

Since I originally had used 010Editor to switch the signature (by script), then write into another file, and had only used the suffix .db, I now - all manually now! - created a new UR file, then copied all regular items (i.e. without Inbox, Recycle bin, Templates, etc.), then 'v of this "material" into the new UR file, worked fine in UR, even after closing the new file and re-opening it.

Then I renamed the UR file, to .db3 this time (instead of, as said, having always used .db as suffix before); then I opened this file in 010editor, and changed, manually now,
the signature,
Ultra Recall DB
= 15 chars, switched to:
SQLite format 3
= 15 chars

I'm positive I didn't make the slightest typo error, or similar.

Then, in 010editor (I'm not making an advertisement, it's just the binary editor I had bought for this task, some months ago),
I did a "save AS", renaming the output file (and leaving its suffix alone).

I then tried to open the file (i.e. original, new .urd, then renamed to .db3, then with switched signature) in Navicat, and again, I got the above error code, even after replacing my "Navicat for SQLite 16" by its newest update... and I remember I had also replaced my Navicat version, some days ago, by its newest update then, and, as said, sqlite3.exe, from sqlite.org, their newest download (I checked again today on their download page) "loads" my UR files, but then, when I do a "select" re a specific table, sqlite3.exe pretends, "no such table".

All the above seems to indicate that the "newest" SQLite3 format (as treated by both the brand-new versions of sqlite3.exe (some weeks old) and Navicat for SQLite, version 16 (both from some weeks ago, AND from "today" or just some days old) has deviated from what UR produces / stores, independently of the file suffix, and of the file signature.

"Download" errors could be excluded, I think, since after my initial problems with sqlite3.exe, I had downloaded, and installed, it a second time, and my - "brand-new" (I hadn't done further tries after my last post here, some weeks ago) Navicat problems today, with a Navicat version just some weeks old, AND with my brand-new Navicat download of today, i.e. in both versions today I get the same problem, totally parallel / imitate ma sqlite3.exe problems described some weeks ago.

Thus, independently of my SQLite front-end being Navicat (from some weeks before, checked today), Navicat-newest (downloaded and checked today), or sqlite3.exe (downloaded and installed two times with the same result, always the very latest version), I do NOT have access to my (renamed and signature-switched) UR files anymore, even to brand-new UR files - not from "within UR" (by sqlite3.exe), nor when those db files are "freely available" (i.e. closed in UR).

I can't send you those files, bec/of their respective content, but I affirm that
- I'm 100 p.c. honest
- I have applied the utmost care and attention to anything done and referred
- I can't imagine 010Editor is the culprit here (as said, I did the signature changes by script before, whilst I've now done them manually)?:

I now have hex-compared, in Beyond Compare 3, the "result" between
- UR file just renamed to .db3 now, and
- UR file after manual-now signature change, and this is weird:

D:\UR\OTRIAL_just_renamed.db3
vs
D:\UR\OTRIAL_just_renamed_then_signature_change(th en save_as).db3

I would need to be able to send a screenshot now but don't know how to do that; "original" (i.e. first) file (hex start):

original file
55 6C then 2 blanks!!! 74 then 4 blanks 72 then 1 blank then 61 then 1 blank then 20 52 65 then 1 blank then Ul t 1 blank

etc

>

My UR installation does not work correctly anymore, obviously, will have to reinstall!

Second file start (i.e. after the signature switch):
53 51 4C 69 74 65 20 66 20 66 66 6F 72 6D 61 74 20 33 (7 blanks, then) 00 04 00 01 01 04 40 20 20

the 53 51 4C 69 74 65 20 66 20 66 66 6F 72 6D 61 74 20 33 obviously being the correct "SQlite format 3" change (Beyond Compare just displays the non-identicals in this setting).

I obviously have a hardware problem which has affected my UR installation... (but nothing else, it seems?)


EDIT 2:

I just discovered your new version, from June 11 (the last one of my multiple update checks had been just days ago) - so it's 64bit now?!!! The link just guides to your general version 6 page, so I can't see what's really new here - this is a recurring problem of your "history" or "what's new" links, they, most of the time, just go to the MAJOR version's updates, not to the fine-grain, in-between version, so they are useless most of the time, and then, finding the specific-version updates, most of the time, I don't get to them.

This being said, it would be WONDERFUL if you updated UR to 64bit, from 32bit, at last, and make it a "major" i.e. paid upgrade soon, I'd be happy to pay... IF then you also addressed some of those ugly GLITCHES... which never ever have made me lose ANY item, but which are so awful in the daily interaction with UR! Hopefully, too, 64bit will now allow for BIGGER database, possibly in the 6-figure item count? (As said, I've got lots of problems with "bigger" databases, and 50,000 items had seem to be a "reasonable" limit to me, up to now, in order to not multiply my problems... if that now, or soon, will be changed to some really bigger number of items, to even 300,000, that would be wonderful! As said, I had to divide my items into about 30 UR databases, which is manageable, BUT (since it's SQLite3) search is db-specific, and linking to "external" databases is technically possible, but really awful, in direct comparison with links within the same db, so I would so much like to be able to re-unite my 30 UR databases into just one... with the management of 300,000 items becoming manageable, that is, and that had not been the case before: so with 64bit, I should try again? or wait some months?)

Unfortunately, the above-described problems persists: UR databases (with suffix .db or db3, and with changed signature, and which correctly open in (just-downloaded-updated) UR, do NOT open in (just-downloaded-and-updated) Navicat, and trigger the error-code mentioned above, instead.

Whilst the beginning of the hex is:

53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00
04 00 01 01 04 40 20 20 00 00 19 C1 00 01 4C 5D
00 01 4B D7 00 00 00 6D 00 00 00 EC 00 00 00 01
FF FF EC 78 00 00 00 00 00 00 00 01 00 00 00 00
etc

I had to copy this manually, one-by-one, but checked then. I'm really stuck here. UR files not open in SQLite front-ends anymore, even without having fiddled "externally" with them in any way, that's a nightmare. Please check!


EDIT 3:

To clarify the "update" hint: on your download page
https://www.kinook.com/UltraRecall/download.html
you always just put the link to your "History page" in your help file, which is devoid of almost any interest; users AND prospects being interested in the most recent developments, and then you search, and search, and search... and then give up. I know there's a very precise, and very helpful, 6.xx history page somewhere, I'm just fed up to invest another 5 minutes, EVERY time, to get to that page... and prospects will certainly not search for that, more specific, up-to-date "history" page. Hence my suggestion, please make a todo, to update that "download page" history link, every time you do any (minor or major) update!

And please, tell me, is the "reasonable item count being about 50,000 items (when they are almost exlusively (formatted) text only)" (which you may contest, but which I inferred from extensive use of UR, with, in total, about 300,000 items of that sort), MOSTLY due to:
- SQLite limitations
- UR design
- 32bit vs. 64bit?

So is there a realistic chance that with your recent / current change from 32bit to 64bit, we could expect a real progress in UR's (practical, not theoretical only) "robustness" i.e. scalability? (I'm aware of the fact that for most single-seat users, i.e. the very big majority, 50,000 items is more than they will ever have to administer, but especially for little work-groups (and then for the minority of users like myself who got "more" items than "in general"), this would be a BIG step forward, also marketing-wise, relatively cheap work-group "information managers" being extremely rare...! (As said above, both linking / cloning (transclusion in general) and (db-specific, by SQlite 3 itself) full text search are "underwhelming" when you have to use a dozen or more UR databases, instead of using just one.) - if it's SQLite 3 itself which is responsible for those "reasonable limits", I'd understand we'd have to live with it, since it's obvious that we couldn't ask for a Postgres server instead, as UR's "back-office" (which would have, and also for free, just like SQLite 3, integrated full text search, too, and where half a million, or then a million, of items would not be a problem anymore.)

Last edited by Spliff; 06-19-2022 at 10:32 AM.
Reply With Quote