FW: RSTLIB problem

Further testing proves that it is not the RSTLIB command that is at fault,
after all.  

The file was being duplicated into the work library on the development
machine rather than recreated from source.  Apparently, the crtdupobj
command retains the link to the original source library (as it probably
should) and compares that to the same library on the restoring machine. 

Nevermind........duh

> -----Original Message-----
> From: Smith, Nelson [SMTP:NSmith@lincare.com]
> Sent: Friday, August 10, 2001 3:33 PM
> To:   'midrange-l@midrange.com'
> Subject:      RE: RSTLIB problem
> 
> > >>>>>>>>>>>>>
> > 3.8.9.6 How the System Restores Files with Shared Formats
> > 
> > When a database file is restored and that file, before it was saved, had
> > shared the record format of another file, an attempt is made to find the
> > file whose format was shared, and re-establish the original format
> > sharing.
> > 
> > The search for restoring the shared format starts in the library to
> which
> > the restored file is directed and continues in the library from which
> the
> > restored file was saved. Following are the results of the search:
> > 
> > If the sharing file is found and has not been changed (level check)
> since
> > the save, then no new format is created for the restored file.
> > 
> > If the sharing file is not found, or it is found but fails the level
> > check,
> > then a new format for the restored file is created with the same
> > definition
> > as the one it initially shared.
> > 
> > If a format sharing file has been renamed, deleted, or moved to a
> library
> > other than the save or restore library, a new format is created for the
> > dependent file when the dependent file is restored.
> > >>>>>>>>>>>>
> > 
>       [Smith, Nelson]  This seems to indicate clearly that the RSTLIB
> command is checking the save and restore libraries only for pre-existence
> of
> a format sharing file.  However, in my tests, both libraries are newly
> created work libraries that have never even existed before, much less
> contain a copy of the file.  The file was compiled from source into the
> save
> library, not copied or moved. I have even tried restoring the file with
> the
> production library which really contains the file removed from my library
> list and it still seems to find it.  Apparently, it is searching the
> entire
> system and not just the save and restore libraries as stated above.  
> 
>       So,my question is "Is the RSTLIB command functioning wrong, or is
> the documentation above wrong?" 
> 
> 
> 


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message. 
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer. 
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************