Databases across Workspaces

[Chris Kelleher]

Greetings and salutations,
I have a problem with my current Roundtable configuration and new applications being developed here. I'll try to be as brief as possible
I have an existing Roundtable database with numerous products. I've configured each product to have at least 2 product modules (one for the dictionary and one for programs). Each of these products have 2 WorkSpaces (DEV and PROD).
Example
Product Pmodules WorkSpaces
mfg mfgdict MFGDEV MFGPROD
mfgcode
dist distdict DISTDEV DISTPROD
distcode

The DEV workspaces are PRIMARY sourced to themselves. The PROD workspaces have the associated DEV for the source.
Problem:
These products were in the past separate and now they need to be able to exchange data between the different databases.
In order to compile properly, programs must only reference databases within their own WS.
(ie How do I reference both the mfg database and the dist database in one program from within Roundtable).

I have figured a way to run programs with input and output parameters; but, not very practical.
Would adding another WS be a solution ?
TIA
______________________________________________________
Steve G Brown
Database Manager
DANA Brake & Chassis
[HP/UX 10.20/11.0][RTB 8.3B][Prog 8.3B]

 

[Chris Kelleher]

Steve,

I'm not sure I understand the question, but I
think you are saying that you have duplicate
table and field names between the two databases
so that you cannot compile if both are
connected. If this is not the case, disregard
the rest of this message

If you look at rtb_evnt.p in your RTB root
directory, you will see that you can intercept
the compile hook. This means that you can
massage connections at compile time.

1. Import the second database into the workspace,
enter the new connection information, and update
the schema.

2. Blank out the physical DB name so that RTB
does not connect to it when you select the
workspace.

3. Intercept the before compile hook and screw
with the DB connections. I.E. disconnect the
normal one, connect the second.

4. Intercept the compile hook (actually an after
compile hook) to put things back to normal.

When you select a workspace, RTB connects to any
databases listed with a physical name definition
using the Progress connect statement. When RTB
compiles, it simply uses a "compile" statement to
do a normal every day Progress compile with XREf.
After that compile is completed, RTB takes over
and looks for the object names for the schema
listed in the xref file that the compile spit
out.

Everything passes as long as the Progress compile
is happy and then the xref is happy. When
databases are connected to or disconnected to is
irrelevant.

-Gerry

 

[Chris Kelleher]

Thanks for trying Gerry but No I do not have any duplicate table and field names between the 2 databases.
The 2 databases are in separate workspaces, which previously did not have to interact.
Now with our business changing, we want to pass data between the 2 databases
Example
Prog1 located in WS1 accesses DB1 (also in WS1)
Prog1 connects DB2 and runs Prog2 . [ DB2 not in WS1 but in WS2 instead]
Prog2 references both DB1 and DB2.

Prog2 wont compile in WS1 because it references DB2 that is not in WS1
Prog2 wont compile in WS2 because if references DB1 that is not in WS2
Where can I put a program that references both databases ?

______________________________________________________
Steve G Brown
Database Manager
DANA Brake & Chassis
[HP/UX 10.20/11.0][RTB 8.3B][Prog 8.3A]

 

[Chris Kelleher]

Steve,

Roundtable expects the entire functional application to be included in each
workspace. In other words if the business rules now say the prog2 accesses
db2 that db2 needs to be in the same workspace as the prog2. Just because
the program is in that workspace doesn't mean you need to modify it there,
for manageability I would still manage db2 in WS2. In other words source
WS2 to WS1 and include the DB module and import the db2.

The only other alternative, and this is a hack, is to Assign the db2 PDBASE
object into the WS1 with your module xref level set to 6 which does not xref
schema. Again I don't recommend that but it would probably get you by.

Nathan Noll (817) 284-8680
NCS Fax (800) 538-7510
Certified Roundtable Consultants nathan@nollc.com

Check out F1 an integrated Change Request System that works
with Roundtable! www.nollc.com/f1

 

[Chris Kelleher]

Another option I have used (about 3 years ago in RTB 8.2??) is to just
create a PDBASE object for the database you only want to reference and point
it to the physical database in the other workspace. To do this, I think we
might have had to switch off cross referencing for the module as the tables,
fields and indexes didn't exist in that workspace.

Example (only dev workspaces)
Product Module Contains
------- ------ --------
mfg mfgdict mfg/pro schema
mfgcode mfg/pro code
cust custdict custom (side) database
custcode custom code

To make it work, you can create a PDBASE object called qaddb in the custdict
module and point it to the database from mfgdict. You will need modify the
cross referencing for custcode to not include the database schemas (I think
you can still cross reference programs).

There is another less elegant solution where you create a whole new product
for programs that reference both databases, but it still uses this idea of
creating PDBASE objects that only reference the database and don't have the
schema in the module.

I hope I haven't completely confused everyone.


Jamie Townsend

 

[Chris Kelleher]

I've said it before and I'll say it again NATHAN RULES
Many thanks
______________________________________________________
Steve G Brown
Database Manager
DANA Brake & Chassis
[HP/UX 10.20/11.0][RTB 8.3B][Prog 8.3A]

 

[Chris Kelleher]

Hi
We do it the following way:

DB Version is in WS dev, test and prod, it is only one DB that is physically
located and administered with prod WS.

To do a change on the DB the changes are made in dev WS. (all other DBs are
down during that time, because every WS connects to this DB)

In WS dev the Schema Changes are applied.

The changes in the common DB are then propagated through all other WS's via
Import. In all other WS's the import has to be done without any changes to
other DBs. Call Schema Update, Build, then SKIP ALL and Update.
Now all Definitions are known ot every WS without damaging the DB.
In each WS the same DB (actually the one defined in prod) is connected to
the corresponding PDBASE object.

You are able to compile and run every program you want.

A bit clumsy solution but it works.