Databases between libraries are not shared, I.E. when the function is called it will look in the current projects database ID and not the Libraries project ID in order to resolve this issue you can
A:) force a request to the database using startWebRequest for the path /datablock_storage/:id/read_records?table_name=:name this way you won’t need to re import a dataset on every new project you need the library for
B:) just import the project data from the library to the main project since the caller of the library is relying on the table to be on the main project if you move it there it will resolve it but will make it less convenient to use since it has a dependency that has to be manually added to actually use the library
Overall if your just starting I’d recommend Option B however do note that it is not within best practice to recommend this solution to be used. these paths for example allow you to access data from other projects which is what would eliminate having to re-install that database every time Option A is more ideal as it is more complex but more straightforward with users who’d wish to practically use it.
Perhaps an analogy would be better, when buying a table and the instruction manual isn’t included in the packaging! it’s frustrating not knowing how to put it together right? in this analogy you would be the person selling the table without the instructions and the buyer would be the user trying to make practical use of the table they had bought and wouldn’t be any issues when assembling it. making it clear to users that there are dependencies can mitigate it but is often discouraged if there’s a way to already have that information so that the user doesn’t have to spend more time fixing the library then their own project