You did not answer this...
Sorry... I just want the actual timestamp from the column time. Now it is a different number.
OK
SELECT MAX(time) FROM lastTimestamp
returns a single value
1716058811246
Try a
SELECT time FROM lastTimestamp ORDER BY time DESC LIMIT 1
Taifun
I am not expecting it to be a list, I just expect it to be the actual timestamp and not something like -1930814470. I see I pasted in the wrong screenshot...
So I get this negative number instead of the timestamp. I can see the last part of it change, as you would expect from a timestamp, but it isn't the value of the timestamp. It somehow gets changed...
OK, I am seeing that output too, tested with both commands:
and
Don't have that issue when running the query on SQLITE Browser app though
investigating....
Thanks a lot for your help. Thought I was going crazy (still unsure ; )
I will follow up tomorrow.
Figured it out. SQLite and/or the extension, is treating your time column integer values as date/times (unixepoch), so something funny happens to them when handled by the extension and imported into AI2.
You can CAST an integer to a string, then everything is OK.
Change:
SELECT MAX(time) FROM lastTimestamp
to
SELECT CAST(MAX(time) as TEXT) FROM lastTimestamp;
SimpleSqlite returns the value in a list, so get the first item, then apply the value to your query
Note1:
You could overcome this by setting your time column in table lastTimestamp as text instead of integer (like you have in the stickdata table)
Note2:
As a sanity check, I tested the table column values out on @Taifun's Sqlite extension, which worked just fine without needing to cast the value to a string.
Thank you so much. I guessed it had something to do with typing but didn't know how to go about it. I will look into using the @Taifun extention.
I suppose the other problem I had came from the timestamp, but if not I will get back with the solution or further issues.
Hi,
My data don't get written to sqlite from screen login. I use the same setup in screen1 and there it works.
The strangest thing is that I have managed to store data once from the login screen after setting file permissions (that magically turned off). Thought that solved it, but afterwards could not reproduce the result.
Can it be that the problem is that I don't use Screen1?
Put your database in the assets, import it from there to the default database, then export it to /Documents. That way your app owns the exported copy.
Then import the database from /Documents so that you can then read and write.
Then set the database name to the one in /Documents so that you can then read and write.
OK. Thanks a million I will try that!
I tried it. The db is created in /Documents but still no data being written to it...
I think I am going to do the login from screen1 using visibility to switch what's on the screen.
Looks like it is not happy working directly with the database in /Documents (not sure why, will need to investigate further). However you can import that database to the default database, work with it, then export it again once finished.
Looks messy (and it is...)
On first run, import the db from assets, then export to /Documents (use tinydb to prevent this from happening again)
Then import the db from /Documents to the default database
Work with it.
When finished export the db to /Documents
OK. Thank you once more!
You may be able to use the db you placed in /Documents in the first place, if you import it ?
Seems to work OK if the db is saved/exported to the ASD, then set as DBName with that path, but not for paths to shared storage, possibly an Android 13 thing I have not come across. [EDIT - nope, just wasn't in the extension - fixing]
Update to V4krelease
- now allows for the export and dbNaming of databases to Shared Directories - Download or Documents
- it is important to use an absolute path to the Shared Directories:
- e.g.
/storage/emulated/0/Download/mysqlite.db - use this to either export the database, or to set the DBName property, which will then allow you to open the database in the usual way.
- e.g.
This error also happened to me. I found it happens if we uninstall the app then reinstall it.
or if we delete the db then install again.
and it will return to normal if the DB name in the asset is changed then rebuilt then installed again