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.

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

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

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

SRP Computer Solutions

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

DSig,

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

F:\OINSIGHT SRP Computer Solutions[/url]

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

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 "..\directory" reference.

dbakke@srpcs.com

SRP Computer Solutions

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

View this thread on the forum...