Peer to peer install (OpenInsight Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Peer to peer install (OpenInsight Specific) ====
=== At 01 MAR 2000 10:43:34AM Blair wrote: ===
 
{{tag>"OpenInsight Specific"}}
 
<QUOTE>
All,



We are getting ready to do a peer to peer install of our OI application.  Two issues are unresolved in my mind:



1) should all workstation use the samed mapped drive letter to access OI?



2) should the workstation that OI is installed on access the app through the local hard disk or a network drive mapped to the disk?



Responses are greatly appreciated.
</QUOTE>
----

=== At 01 MAR 2000 12:56PM DSig wrote:  ===

<QUOTE>Blair,



As for drive mapping .. here is what we do in our apps ..



On some system we have a directory structure like



\Appname

\appname\data

\appname\data\...

\appname\data\...

\appname\program (oidirectory)

\appname\program\...



Then in the environment record we call a StoredProcedure which attaches with something as simple as:



LoginProcess(a)

Call Attach_Table("\appname\data\...")

Return



Since the login process is in the environment def record for the app it happens whether you go into dev mode or run mode.



To make this all work be sure not to use 'save database' but instead have the appname.dbt be the same as Sysprogs ... just attach what you want 



hope this helps



DSig

</QUOTE>

----

=== At 01 MAR 2000 12:58PM DSig wrote:  ===

<QUOTE>Blair ..



Opps for got question 2



If you can you should have this on a system(drive) that is not being used for other purposes.  We have found it a little fast this way.  But in real life it doesn't much matter as long as you do not 'save' your definition (not mentioned in the previous post) but use the attach at login time.



Dsig



</QUOTE>

----

=== At 01 MAR 2000 03:35PM Don Bakke wrote:  ===

<QUOTE>Blair,



Since I have a little more familiarity with Buyer for Windows I'll answer a little more specifically:



1. Since your main data directory is underneath the OI directory it doesn't really matter whether the drives are mapped the same. Your .DBT file (which stores the paths of your tables) won't store absolute path names so it will work on any mapped drive. In Dsig's case, his data directory is above (or parallel) with OI so if he were to update his .DBT file it would have to store the full path. This would obviously be a problem as other users who use different mappings will have trouble. The only other time different mappings can cause a problem is if your code makes a reference to an external file on the network (like a bitmap signature for instance.) If this is stored outside the OI directory structure you will have problems.



2. Since this is a Microsoft peer-to-peer network, I don't believe you can get the "file server" to map to itself. It will always have to look at its drive as a local one.



dbakke@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 01 MAR 2000 04:05PM DSig wrote:  ===

<QUOTE>Don,



Don't you think that 'generically' (sp?) it is best to not store absolute drive letters allowing the startup routine to decide where that information should be?







DSig

</QUOTE>

----

=== At 01 MAR 2000 04:49PM Don Bakke wrote:  ===

<QUOTE>DSig,



Yes, but that was kind of my point. If the data directory is stored underneath OI...



F:\OINSIGHT   SRP Computer Solutions[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 01 MAR 2000 04:53PM DSig wrote:  ===

<QUOTE>Don,



Really?  Has it always been this way?  I believe we went to our method because it used to store the drive .. humm .. pretty sure this was a workaround at one time.



anyway .. good info .. thanks



of course this does mean that you are locked into the OI directory.



DSig

</QUOTE>

----

=== At 01 MAR 2000 05:01PM Don Bakke wrote:  ===

<QUOTE>DSig,



AFAIK it's always been this way. Fortunately we have always standardized that our data folders to exist underneath the REVBOOT directory for both AREV and OI.



We have one client who does their own inside development and we offer advanced assistance. They market AREV and OI applications so they keep their data directories in parallel to the AREV and OI REVBOOTS. Before any new deployment we run a utility from within OI that scans the .DBT file and replaces all absolute path references with a "..\[i]directory[/i]" reference.



dbakke@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 01 MAR 2000 08:00PM Blair wrote:  ===

<QUOTE>Dave & Don,



Thanks so much for your guidance.  This is my first peer-to-peer install.  I really want things to go a smooth as possible ? as we all do.  I?m seemed to me, way back when, that all users of Arev had to access arev.exe from the same logical drive in order for the network drivers to work correctly.  This assumption may be the result of foggy memory. 



In any event, the app is up and running and locking on a 5-user peer to peer network.  I admonished their systems guy as to the absolute necessity of daily backups.



Thanks,

Blair

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=41E9496EC983058A85256895005662E7|View this thread on the  forum...]]