HP remote database access.

[pickerij@norbord.com]

And yet another thing -- nowhere in my scenarios below have I accounted   
for deletions from the primary database! I guess you'll need to add a   
pass through the secondary database linking back to the primary base   
optionally and selecting those records in the secondary which are no   
longer in the primary :-(

Might just be simpler to store the primary base to tape and restore it on   
the second box!

Makes shadowing products like Netbase look pretty good doesn't it :-)

JWP

 -----Original Message-----
From: pickerij@norbord.com
Sent: Tuesday, July 21, 1998 6:07 PM
To: john@beechglen.com; powerh-l@lists.swau.edu
Subject: RE: HP remote database access.

 << File: ENVELOPE.TXT >>
 --------------------------------------------------------------------------  
 --


>I am investigating syncing up identical HP Image datasets via the HP3000
>remote database access feature of TurboImage.
>
<snip>
>
>Now, lets say we have SYSTEMS A and B with each having the identically
>structured database named HOSP with a MASTER named PATIENTS and a DETAIL
>named VISITS.  System B is for reporting purposes and non-destructive
>development only.  I am thinking of periodically syncing the sets on
HOSP:B
>to the sets on HOSP:A.
>
>I know from the Turbo' manual that one sets up file equates and such.
 How
>exactly though would this be done to say allowing...
>
>ACC VISITS of HOSP:A to VISITS of HOSP:B   ?
>  ...code here determining if record in B is diff from A and if so
update B
>  ...
>EXIT
>
>I tried:
>:DSLINE nodename
>:REMOTE HELLO logon stuff
>:FILE REMOTEDB=HOSP:nodename
>:QUIZ
>  ACC VISITS OF HOSP LINK TO VISITS OF REMOTEDB
>
> I learned that one cannot qualify the filename with a database name.
>Would this mean that to accomplish my goal the database would need to be
>described twice in the dictionary once for HOSP that resides on A and
say a
>B-HOSP with  B-PATIENTS and B-VISITS sets?
>...
>  ACC VISITS LINK TO B-VISITS
>
>What am I missing?  Is their an easier method?


Sorry John, there's no easy method. And you won't like my suggestions
unless the datasets are pretty small and not likely to change too often.


One possibility is to create a duplicate definition in the dictionary as   
    

you suggest. The second definition can give some different open name and   
    

that can be file equated to the second and remote machine. Another option   
    

would be to unload the datasets of the primary database into subfiles and   
    

then use the same dictionary (with only a single definition of the
database) and appropriate file equates to access the secondary database   
    

and do the update. This would allow you to do the processing on either
machine (i.e. by accessing the second database remotely or by using
dscopy to put the subfiles on the second machine and doing the update
entirely on that box).


And when you get to that update step you won't be too happy either. I
can't think of an easier way to update "anything that has changed" in the   
    

secondary database other than an output update add (which would require a   
    

two pass request or a unique key) and an item statement for *every* item   
    

in the dataset. And about the only way to automatically generate all
those item statements is to let qtp generate them as item initial
statements and then cut and paste with your favourite termulator and turn   
    

them into item final statements. And don't forget to update this anytime   
    

the primary database changes!


Told ya you wouldn't like it :-)


John Pickering
JWP Systems Inc.


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =   
=
Subscribe: "subscribe powerh-l" in message body to   
majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to   
majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.



= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.