Runtime and Split Database

Okay - thank!

Klatuu wrote:
>Bonnie,
>I saw nothing really incorrect, but more incomplete. I was just trying to
>add detailed information to help the OP.
>> Thank you and Klatuu for the addition details/information. Just to be sure
>> of myself - was there something I said that was incorrect?
>[quoted text clipped - 20 lines]
>> >with a full copy of Access from opening it. Your design would be safe from
>> >users who had ONLY the runtime installed.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-setupconfig/200808/1

Klatuu <Klatuu.DeleteThis@discussions.microsoft.com> wrote:

>I also recommend you use UNC paths rather than Drive Map paths when linking
>to the back end. It is more efficient

I don't see how using UNC is more efficient than drive letters.

>and it prevents any problems when all
>users don't have the save drive letter mapped to the backed mdb location.

Using drive letters was quite handy for me the developer at one
client. I did a Command Prompt Subst to point to a local folder
name and ran my app when testing on my system. Then if I needed to
work on the live app I just removed the Subst and did a Net Use on
the drive letter. Granted though everyone had the same drive letter.

>I recommend deploying only an mde, particularly if you have any users
>with full Access installed.

It's also more difficult for an employee to steal the MDB which is the
corporations intellectual property.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

"Tony Toews [MVP]" <ttoews DeleteThis @telusplanet.net> wrote in
news:rmu6b4hd7to1b3t0mevjak8jbhiddqsusi@4ax.com:

> Klatuu <Klatuu DeleteThis @discussions.microsoft.com> wrote:
>
>>I also recommend you use UNC paths rather than Drive Map paths
>>when linking to the back end. It is more efficient
>
> I don't see how using UNC is more efficient than drive letters.

Because a drive letter is resolved to the UNC path to be used.

It also removes any dependency in your app on someone correctly
configuring the PCs on which it runs (either local mapped drives or
a logon script that maps the drives for all PCs).

I have been deprecating mapped drives with my clients since 1998.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

I use mapped drives in house because I support the network and manage the
users and apps. Works well for me. If I happened to move my app to a new
server with different naming I could map the drive to it and not have to make
any programming changes (or relink the tables). If I hard code the UNC I'll
have to modify the code (and relink the tables).

Bonnie
http://www.dataplus-svc.com

David W. Fenton wrote:
>>>I also recommend you use UNC paths rather than Drive Map paths
>>>when linking to the back end. It is more efficient
>>
>> I don't see how using UNC is more efficient than drive letters.
>
>Because a drive letter is resolved to the UNC path to be used.
>
>It also removes any dependency in your app on someone correctly
>configuring the PCs on which it runs (either local mapped drives or
>a logon script that maps the drives for all PCs).
>
>I have been deprecating mapped drives with my clients since 1998.
>

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-setupconfig/200808/1

"bhicks11 via AccessMonster.com" <u44327@uwe> wrote in
news:8943a4e614b7b@uwe:

> I use mapped drives in house because I support the network and
> manage the users and apps. Works well for me. If I happened to
> move my app to a new server with different naming I could map the
> drive to it and not have to make any programming changes (or
> relink the tables). If I hard code the UNC I'll have to modify
> the code (and relink the tables).

Why do you have code that refers to drives?

In the same situation, I simply distribute a new front end pointing
to the UNC path of the back end on the new server.

Perhaps you are making your own problems by insisting on using
mapped drives (which is the way I see it, and why I completely avoid
them where I can -- that is, regardless of whether my client's
network is set up with mapped drives or not, I never use them in my
Access apps, and instead use UNC exclusively).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

I see your point and agree its better in most circumstances. But I'm in a
small office and not distributing my apps so it works fine for us. I'm on
Novell and would find it easier to create one login script that everyone runs
to map drives rather than modifying the front end and redistributing it if I
changed a server.

Boy, you guys get passionate! I'm kidding - thanks David!

Bon

David W. Fenton wrote:
>> I use mapped drives in house because I support the network and
>> manage the users and apps. Works well for me. If I happened to
>> move my app to a new server with different naming I could map the
>> drive to it and not have to make any programming changes (or
>> relink the tables). If I hard code the UNC I'll have to modify
>> the code (and relink the tables).
>
>Why do you have code that refers to drives?
>
>In the same situation, I simply distribute a new front end pointing
>to the UNC path of the back end on the new server.
>
>Perhaps you are making your own problems by insisting on using
>mapped drives (which is the way I see it, and why I completely avoid
>them where I can -- that is, regardless of whether my client's
>network is set up with mapped drives or not, I never use them in my
>Access apps, and instead use UNC exclusively).
>

--
Message posted via http://www.accessmonster.com