October 25, 2017 at 4:29 pm
We have a situation like below:
we have a .net application for students that used the SQL server database as backend, I will call it App1. The database have some tables for the application and also import a lot of tables from our main
enterprise student info application based on Oracle I will call it App2. We are allowed to do customization into the student info application APP2, but we created App1 separately as a small application program for just deal with Student Truancy.
As the customer requests, and the scope becomes bigger and bigger, we will have to import more and more tables into App1.
.net can call directly from code for the oracle database by using OLEDB driver , I wonder if we should do that instead of we have to importing more and more tables in situation
code , reports that only need oracle tables.
Thanks
October 25, 2017 at 5:38 pm
sqlfriends - Wednesday, October 25, 2017 4:29 PMI wonder if we should do that instead of we have to importing more and more tables in situation code , reports that only need oracle tables.Thanks
Can you explain this part, please? I don't know what you mean by 'situation code'.
What is the relevance of 'reports that need only Oracle tables'?
What sort of help are you expecting?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 25, 2017 at 7:15 pm
Sorry.
Just tried to figure out which is the good option:
to continue to do many table imports from App2 to App1 nightly?
Or ask .net developers to use some .net code directly call oracle database?
The latter situation is when the user interface only need tables from oracle, that will be real time data.
If data displayed in UI or reports needs data from both database in APP1 or APP2, then we use the SQL database. and only import those tables needed to SQL databases.
October 25, 2017 at 7:17 pm
when I say reports are some SSRS reports embberded in the .net application.
October 26, 2017 at 10:20 am
It sounds like you need to rethink (as you are doing) the scalability of these applications/databases.
If I understand you correctly, you need additional tables from Oracle for reporting purposes. Because of this, you would like to know if you should import the tables into SQL nightly, or simply change the SSRS reports to point at the Oracle database.
One of the things we don't know is how busy are the tables in Oracle? Reporting could potentially lock tables when data transactions are being attempted.
A separate option that you haven't mentioned would be to create a reporting database where you copy data into it nightly for reporting use, where the .net applications can freely operate.
In any case, not knowing how busy the Oracle database is and what the expected future growth will be limit our ability to give you a concrete answer.
October 26, 2017 at 10:27 am
Thanks much.
We also have a lot of SSRS reports on another that connects the Oracle database in real time. That is for the customized reports we created for App2. It is OK to do the direct connection to App2, we have very powerful resources for that server.
October 26, 2017 at 10:31 am
If you are already using Oracle for reporting purposes, then I would tend to keep the tables in Oracle and provide access to those table for the .net app instead of duplicating effort.
That is, unless there is some other underlying reason not to do that.
HPH,
Dan
October 26, 2017 at 11:36 am
dreynolds 13587 - Thursday, October 26, 2017 10:20 AMOne of the things we don't know is how busy are the tables in Oracle? Reporting could potentially lock tables when data transactions are being attempted.
Just as an FYI in Oracle readers don't block writers (unless Select .... For update is used). Similarly, writers don't block readers
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply