Thanks for the question, Carsten.
Asked: November 05, 2020 - 3:50 pm UTC
Last updated: November 10, 2020 - 11:20 am UTC
Version: 12
Viewed 1000+ times
You Asked
Hi Tom,
I'm developed an ecu test application in .net for our department.
The test data is stored in our remote Oracle Server.
In the past years every time when I needed data I just open a connection to the Oracle server from my c# application and requested on demand all the data I need for the job.
Now I have the aim to have all the data locally and only update the local database if there are new data in the master oracle table.
That's because I want to run "old" tests with my c# application also when no connection to the oracle server is possible.
In the past days I did a lot of research how to get this done. But there are so many possibility that I'm lost for now.
Can you give me a hint which solution can do my requirement?
On the local side I think about a SQLite for the .Net application. But maybe there are better solutions which are support my requirement from oracle.
Only I want the same Oracle table data on my local DB. Only one way.
If I have connection to the Oracle the local should be updated with new master data.
It would be wonderful when you give me a hint for the right direction for further investigations how to sync one way a local db for .net application.
Thanks in advanced,
Carsten Herkt
and Chris said...
If you're copying data from another database to one running on your machine, probably the easiest option is:
Data Pump Export/Import
If you can arrange for a (schema or full) export of the source database regularly (e.g. daily), then you can import the latest data into your database whenever you need.
If for whatever reason you're unable to get an export file created, you could do a network export/import.
If the source database is "large", this process could take a while. You can get around this by scheduling the import to run in the early hours before you start working. Or by limiting the process to the few tables you want to update.
Once the import is complete, your database is independent of the original, so you can manipulate it however you want. If something goes horribly wrong during testing (e.g. an app bug leading to junk data), you can revert back by re-importing the data.
On the local side I think about a SQLite for the .Net application
You want the configuration of the test database to be as close to the production database as possible. Loading data into a different RDBMS breaks this principle. This may invalidate many of your tests due to database differences.
Avoid doing something like this at all costs! This applies whatever the source RDBMS is.
Is this answer out of date? If it is, please let us know via a Comment