Using SUBST command for linked databases. 1

[lcapece]

The long forgotten SUBST Dos command can be very useful for using linked, network mapped, tables in an "off network" develpment setup.

SUBST creates a virtual drive letter and enable the develper to "simulate" the network drive.
I recently has one client who had a front-end/back-end Access Db. The front end has tables linked via drive letter S: (did not use UNC naming).
create an S: drive on the local machine (will actual be C

SUBST S: C:

This allows the linked table to be read "as-is"

 

[MichaelRed]

Perhaps, ... but you're just delaying the fall.

Go ahead and fix it w/ UNC and save yourself (and your client) the hassle of needing to fix it next time (sooner).

Most of the 'good old" DOS stuff is going to disappear in some (soon to be released) ver of Windows.

Keeping the Subst command just makes the installation on another machine one step more removed from straightforward.

You are not making any money by leaving the trouble alone. I would liken this to the mechanic who worked on my car and noticed that I was inexplicably running on the *()&^@(#*&^%@(&^# little "Mini Spare" which is popular these days and thought this was a neat way to keep from buying a new tire.

You customer will NOT be pleased when he finds out that you left an ancient "Kludge" from the age of dinasours in "His" spiffy new modern database.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[lcapece]

I think you mis-understood this levity of this post.
Yes, UNC'ing is the proper way, but if you are developing or fixing a front-end/back-end db offsite, SUBST is a quick way to resolve the links to the table when you can't get access to the network and it's UNCs or dont want do write code to link/re-link the tables.

In this case mentioned, the client did insist for their own reasons that mapped drive letters be use.

This post is not a recommendation to use mapped drives, but rather a tip for situations where mapped drives are already in place.

 

[harryrich]

I agree that when there is a single instance of a back end database in your network that UNC naming is the proper way to reference it. Unfortunately, this is hardly ever the case. Even if the data has a single universally shared instance in the operation, there are still uses of the application such as testing, training, and demonstration which dictate that the application be able to reference data in a different network location without modification.

Historically, this has been accomplished by placing a drive reference in the application and configuring that drive's mapping on a per user and/or per workstation basis.

I agree with the comments on the kludginess of this approach since (1) there is nothing in the drive naming to indicate its application, and (2) the limited number of drive letters makes them a scarce resources that have to be carefully managed in your network.

So, I guess I have two questions:

(1) Have I, and a number of network administrators been overlooking a feature that allows per workstation and per user profiling of UNC addresses in NT networks?

(2) Does DFS or some other feature provide this in Windows 2000?

Thanks,

Harry Rich

 

[MichaelRed]

Mr. Rich,

It is NOT your problem / Issue (at least as a net admin). It is the datbase designer / programmer.

UNC's offer the ease and flexability to do all of the re-direction necessary to connect to any available db for testing | documentation | Demonstration | training | use the same front end with multilple data sources.

I often build a single (LOCAL) table into a front end which has the various UNCs and use this in the startup process to select the "proper" database for the user. Just as Often, this selection is simply based on the user login information from the security (MDW) file info (UserName / Group), so the process is "transparent" to the user.

If you are a db programmer, you should know all of the above - and use it. If you are a network administrator you should MAKE your db programmers be aware of this - and USE it.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[harryrich]

Mr. Reid:

First of all, let me make it clear that I think the UNC addressing scheme is a fine way of mapping a network environment. I have no compelling criticism of it as an absolute addressing scheme. And, I also agree with you that the DOS drives should go away. But, I also think they should be replaced with something much better.

Most MS Windows programmers are so used to dealing with an environment limited to absolute addressing (and absolute everything else, excuse regedit.exe and the like), that they can no longer see what is missing. Of necessity, their application development is directed toward making these applications function in an extremely wide range of environments. While solving this kind of problem provides a justifiable ego boost, the approach itself has the following drawbacks:

(1) A large portion of programmer effort, which could be directed a meeting user needs, is directed towards environmental adaptation;

(2) The more adaptable you make an application, the more difficult it becomes to specify the exact environments in which the application will work. The current community standard to involve making only loose specifications;

(3) Finally, a widely adaptable applicaton can only be tested in a small fraction of its working environments.

I hate to think the amount of time I have spent trying to figure out what it is in the environment that some failing Windows application cannot deal with. Believe it or not, this can happen even when I write them.

Of course, most of us could not limit our applications to a single environment even if we wanted to. One alternative is to take the adaptative mechanisms and move them out of the application and into the OS where they can be centrally specified and tested.

In the Unix OS, which is really the environment where the like of UNC addressing was shown to work, the absolute addresses are supplemented by logical devices assignable to them and by scripting which can be configured to establish the per user variations in the addresses themselves.

Moving to the single user DOS PC the per user configurability disappeared, of course. And moving to MS Windows most of the rest of the environmental scripting disappeared.

I'm not suggesting that any of this be revived. What I am suggesting, is that important functionality is missing and needs to be replaced.

Meanwhile, which kludge is least bad depends on a number of factors in the specific application and environment.

Best,

Harry Rich