I have a SQL command that works on SQLite databases fine. However when I try to run it in Xojo, I get database is malformed error. Works ok in anything else?
here is the structure
CREATE TABLE files (
filename TEXT,
filepath TEXT PRIMARY KEY,
filepath_hash TEXT,
filesize INTEGER,
magic TEXT,
modifydate TEXT
)
here is the code:
SELECT
filename,
filepath,
rowid,
CASE
WHEN years > 0 THEN years || ’ years, ’
WHEN months > 0 THEN months || ’ months, ’
WHEN days > 0 THEN days || ’ days, ’
ELSE hours || ’ hours’
END || ’ ago’ AS modification_duration,
CASE
WHEN filesize >= 1099511627776 THEN ROUND(filesize / 1099511627776.0, 2) || ’ TB’
WHEN filesize >= 1073741824 THEN ROUND(filesize / 1073741824.0, 2) || ’ GB’
WHEN filesize >= 1048576 THEN ROUND(filesize / 1048576.0, 2) || ’ MB’
WHEN filesize >= 1024 THEN ROUND(filesize / 1024.0, 2) || ’ KB’
ELSE filesize || ’ bytes’
END AS human_readable_size
FROM (
SELECT
files.filename,
files.filepath,
files.rowid,
files.modifydate,
files.filesize,
CAST((JulianDay(‘now’, ‘+01:00’) - JulianDay(datetime(files.modifydate))) / 365 AS INT) AS years,
CAST(((JulianDay(‘now’, ‘+01:00’) - JulianDay(datetime(files.modifydate))) % 365) / 30 AS INT) AS months,
CAST(((JulianDay(‘now’, ‘+01:00’) - JulianDay(datetime(files.modifydate))) % 30) AS INT) AS days,
CAST((strftime(‘%H’, ‘now’, ‘+01:00’) - strftime(‘%H’, datetime(files.modifydate))) AS INT) AS hours
FROM files
WHERE files.filename LIKE ‘%sound%’ AND files.filename NOT LIKE ‘%afx%’
ORDER BY files.filename ASC
) subquery
ORDER BY datetime(modifydate) DESC;
Dump your file as SQL, let XOJO create it from from 0 to 100%, and try again. This is specially true if a SQLite file was encrypted. When using different cyphers, for those not matching they are just garbage and don’t even open, for those matching they work.
Trying
PRAGMA integrity_check(integrity_check_fix);
fingers and toes crossed!
im surprised other sql clients don’t report any corruption with the same query odd?
Again, the above message has no connection with a QUERY
If you make a copy of it and delete lots of rows then VACUUM it, making it just a simple small sample, does it retain the “database malformed” behavior for Xojo? If yes, share a zipped sample.
Found the issue, its to do with the Xojo copy files in the build environment. For some reason when it copies a 14GB file from the previous directory it becomes corrupt. Removed it from the copy and pointed directly to the dev environment and it works ok. Will need to build into the installer to copy the data file and not let the IDE do it.
Solved!
Kind of. You may have found a bug. A bug Xojo never noticed because no one never had a 14GB resource file before? It could be interesting reporting it.
It would be interesting to know how it was corrupted though, as in, was it truncated to a particular length, or missing the first few bytes, or something else