From: Marc Verkade [Marti IT] on
Perhaps it is....
But my facts seem to differ from yours.

Anyway, it really does not matter here in my sutuation. I have no issues
regarding this.

It is worth a try.
When you do not shoot, you will always miss!

--
Grtz, Marc


"Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> schreef in bericht
news:vOU1l.2418$cu.1841(a)news-server.bigpond.net.au...
> ..and therefor some other factor is involved. Often it can be as simple as
> the NIC being on auto select or even the hub on auto select. Put GB cards
> in a LAN with 100MB cards and sometimes the same thing can happen.
> Sometimes one workstation has Novell protocols enabled and others not.
> There are a whole range of environmental factors that can affect this. But
> in general, mapped drives should be the fastest access. There is plenty of
> MS material to support this.
>
> Geoff
>
>
>
> "Marc Verkade [Marti IT]" <marcatM(a)rtidotnl> wrote in message
> news:4947f982$0$793$58c7af7e(a)news.kabelfoon.nl:
>
>> But then my measurements don't lie....
>>
>> --
>> Grtz, Marc
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 3696 (20081216) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>

From: Dirk (Belgium) on
Marc Verkade [Marti IT] wrote:

> Hai,
>
> We have seen that communicating through a share F:\App.exe works
> slower than using an UNC path like \\serverip\appshare\app.exe
>
> Perhaps worth a try.

Marc,

I do this already for years, EXE and DBF are always on UNC-Paths,
because:

If your PC starts up, and the drive X: is on that moment not available,
Windows ask the user if he should try to reconnect next time. If user
answers 'No', then drive X: will never be reconnected and you have to
reconnect it manually.

Therefore, I always use \\Server\Share, for both EXE and DBF.

Dirk

--

From: Dirk (Belgium) on
Phil Mermod wrote:

> Hi Dirk,
>
> I posted in this thread a trick related with your (a) and (b).
>
> Did you try it ?

Phil,

This article describe the locking-cache problem...
We used this already many years for solving a problem with flexfiles
(memo's) and caching, and also for stability of the indexes.
After years experience, I had the most stable indexes when setting the
values as follows:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters]
"UseWriteBehind"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters]
"OpLocksDisabled"=dword:00000001
"CscEnabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Param
eters]
"EnableOplocks"=dword:00000000
"CachedOpenLimit"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\
Parameters]
"UseOpportunisticLocking"=dword:00000000
"UtilizeNtCaching"=dword:00000000
"UseUnlockBehind"=dword:00000001

When reading the article of microsoft, I do not know what I have to
change. Which setting must be 0 and which setting must be 1.

How are your values for these settings ?

Dirk
--

From: Paul D B on
Dirk (Belgium) wrote:
> Marc Verkade [Marti IT] wrote:
>
>> Hai,
>>
>> We have seen that communicating through a share F:\App.exe works
>> slower than using an UNC path like \\serverip\appshare\app.exe
>>
>> Perhaps worth a try.
>
> Marc,
>
> I do this already for years, EXE and DBF are always on UNC-Paths,
> because:
>
> If your PC starts up, and the drive X: is on that moment not
> available, Windows ask the user if he should try to reconnect next
> time. If user answers 'No', then drive X: will never be reconnected
> and you have to reconnect it manually.
>
> Therefore, I always use \\Server\Share, for both EXE and DBF.
>
> Dirk

Dirk, why don't you use a login script?
net use J: \\server3\voapps /persistent:yes

Personally, I like drive mappings a lot more. If ever you have to change the
location of your data or application (on another server, in another folder
etc) then all you have to do is change the drive mapping (which is a piece
of cake because you only have to change the login script at the domain
controller). For your VO application it will still be "drive J:" and to
which folder or machine that points, is irrelevant.

As far as I know, there is no noticeable performance difference between
using Mapped Drives or UNC paths.
There have been issues in the past with copying files over a network which
had to do with SMB, see http://support.microsoft.com/kb/885189, but this is
another ballgame.
Those who say that there is a difference between UNC or drive mappings, when
it comes to database access, are kindly invited to post a working sample
here that demonstrates it <g>

--
Paul


From: Phil Mermod on
Hi Dirk,

Same here.

Cheers,

--
Phil Mermod
Crystal Reports Library for Visual Objects
http://www.pkl.ch/dev/


Dirk (Belgium) wrote:

> Phil Mermod wrote:
>
> > Hi Dirk,
> >
> > I posted in this thread a trick related with your (a) and
> > (b).
> >
> > Did you try it ?
>
> Phil,
>
> This article describe the locking-cache problem...
> We used this already many years for solving a problem with
> flexfiles (memo's) and caching, and also for stability of the
> indexes. After years experience, I had the most stable
> indexes when setting the values as follows:
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Param
> eters] "UseWriteBehind"=dword:00000000
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Pa
> rameters] "OpLocksDisabled"=dword:00000001
> "CscEnabled"=dword:00000001
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanSer
> ver\Param eters]
> "EnableOplocks"=dword:00000000
> "CachedOpenLimit"=dword:00000000
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWor
> kstation\ Parameters]
> "UseOpportunisticLocking"=dword:00000000
> "UtilizeNtCaching"=dword:00000000
> "UseUnlockBehind"=dword:00000001
>
> When reading the article of microsoft, I do not know what I
> have to change. Which setting must be 0 and which setting must
> be 1.
>
> How are your values for these settings ?
>
> Dirk