According to the TinyDB docs, you can't access the database between different apps. This is because TinyDB stores the database privately.
I shall get into that, thanks ABG. According to err_invalid_name, i can share data until it's compiled then it privatized. Our governments keep demonstrating that privatization doesn't work...lol
Thanks for your assistance, ABG
thanks invalid, i shall read into that for sure.
Looks like I'll be leaning about text files
I can see I misread that document.... screens, not apps. Thanks for the poke in the eye! 
You could convert the TinyDB to a dictionary, save it to a file, and then access it in another app. Converting the TinyDB to a dictionary would end up looking something like the following image.
There are extensions available which can export and import a TinyDB. You can find them in the extensions directory App Inventor Extensions | Pura Vida Apps
To import TinyDB from another app, you need SAF...
SAF: App Inventor implementation of Storage Access Framework
See also Some basics on Android storage system
Taifun
SAF can select / open file from other app's private dir?
No, App1 exports TinyDB to shared storage and App2 imports TinyDB from there using SAF
Taifun
2 Likes
wow... so much not like the medieval days when you just had a disc to save and retrieve from. 
so store the data on a cloud database is much easier.
you are correct there, methinks, Kevin. at least then i can use the apps whilst i learn about all this other stuff...
An alternative to TinyDB is the TinyWebDB component. It stores the data in one shared database instead of on a per-app database. By default it uses MIT's server but they strongly recommend against using the default server for anything more than basic testing. To run your own TinyWebDB database you could either use App Inventor's instructions or Kodular's instructions (Note: the two different instructions are for two different pieces of software that accomplish the same thing).
So, what I am trying right now is the cloudDB until i set up something else where. What's happening is that the commands execute so quickly that the data has not 'arrived' before the formatting commands are completed and so get an error reporting that there is no data.
Is there a way to suspend execution for even one second to give time for retrieval?
Show your relevant blocks
TinyDB is the only native AI2 database with instant gratification.
All others need to add event blocks to handle incoming data requested elsewhere in your app.
If i hit the load button twice, the data is present on the second click. I am going through to follow the logic again. It is a mess right now as I am converting from a local db to cloud db, so the blocks are very messy. Once I've cleaned them up and if it's still in delay mode, I will post some blocks, but right now, npot even would know what to post...
Like I said to Tim, I am going through and tidying up the blocks as yes, there are several hoops to code through with remote DBs
I forgot to mention a design factor with remote access.
You might need to add global lists to hold data that's waiting its turn to be sent on its way to the server, like in an airport or bank.
You will also need to leave yourself notes in global variables along the lines of What Was I Doing to help the Got Data events decide What Do I Do With This Incoming Datum?
Airport taxi line, hmm. Good point...
Here are the blocks as they sit now, at least the blocks for retrieving data.
What happens is I click on the listpicker selection, it goes to get the data, but as it executes the display_current_record (which actual now ONLY displays the data) it does not update. It will show whatever last record was displayed. If I click again on the listpicker, it will then display the selected record., notably, if I select a different record, it will display the previously selected record.
What I am thinking is that I have to pre-load all the records at initiation into a local, global array, right?
edit* I just moved the *[get_and_display_current_record] rocedure to the end of the .GotValue block, it works there... is it just a delay in retrieval? or is the execution order that sensitive?
Depends on the data volume. Could get slow and expensive.
Maybe divide the data by day?