cazerpa
28th October 2004, 22:31
I am using ORACLE for Baan V, but I need open other database (SQL SERVER) in order to access it, do query on it.
is that posible?
How could I do it?
Carlos Zerpa
malutz
29th October 2004, 08:43
Hej,
we tried the same thing. We didn't even manage to open an other database within the same SQL-Database.
mark_h
29th October 2004, 15:40
We tried with Oracle. We were able to read the data from the other table, but it caused problems when trying to create new tables. We ditched that and just started using export/import script to load the data directly into Baan.
You can always write a little sql script to pull what you need, put that to a file, then read it into the program. No something I like, but something you could try.
Mark
tjbyfield
30th October 2004, 03:45
This reply is for almost the opposite situation. We transfer data "from" and "to" Baan and other database instances (mostly "from"). In our situation we use Oracle for Baan and the other DB instances. Generally and as a matter of policy, we do not update Baan tables outside of baan except by the second example I will give here.
(Situation 1) We transfer data to reporting systems (datawarehouse) and to a non-Baan General Ledger and other systems, from Baan-Job Sessions that call unix scripts that inturn execute Oracle Stored Procedures or inline SQL code. THe unix scripts could also be called from within a baan program. Access across database instances is achieved by "db links". Stored procedures provide amongst other things a programming language (some of our procedures may have 2000 lines)
(Situation 2) We have a 24x7 availability (max out-window a couple of minutes) , production recording with serial-numbered discrete weight/quantity/quality certification with bar-coded label produced as final production step, application that records details in baan system. In this application made-to-order goods may be dispatched within a few minutes of being produced 24x7. In this sutuation the production line uses non-baan inhouse application that runs asynchronously with baan to allow for baan being down for up to a few hours for system/equipment maintenance.
In this application we execute a unix procedure every couple of minutes which uses Stored Procedures to extract production details for the non-baan system and populate a baan table which baan also populates with progress and other details. The unix script also initiates baan program to process the records transferred. This interface table is much like a queue where each users takes the top record and then deletes the record after it is successfully processed. During low production times (holidays etc) this table may process only a few transactions an hour but in high activity times it may handle 100's per minute (such as on restart after a baan down time.)
The situations I have described are fairly substantial interfaces with other systems where we have the same "brand" of RDBMS and dblinks are available.
Why do we have these "Interfaces" ?? The answer is that we won't have them when we have settled on a longer-term ERP platform. We have had Baan for 7 years and generally have been happy with it. However the "cloud" over it has not been fully removed and we still don't know if the new version will address the features of our other applications.
Terry