This query normally takes about 0.5 seconds:

select R.* from Rechnungen R left outer join Patienten P on
R.PatientenID = P.PatientenID
where P.name like  'beck%';

After changing the database folder in the config-file from

g:\daten\myfolder

to

\\edv1\g\daten\myfolder

(both directories are on the same machine) the same query needs about 9
seconds to execute.

Is this a bug?

Regards Uli

Uli,

<< Is this a bug? >>

Yeah, but it sounds like an MS one.  They've had issues in the past with
their OS's and performance when using UNC paths to access data. What OS's
are involved on both ends (client and file server) ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

> Yeah, but it sounds like an MS one.  They've had issues in the past with
> their OS's and performance when using UNC paths to access data. What OS's
> are involved on both ends (client and file server) ?

XP Professional SP2. It's just the same machine for both ends.

Uli,

<< XP Professional SP2. It's just the same machine for both ends. >>

Ahh, in that case the issue is simply that using UNC makes the requests go
through the network redirector, which slows things down a bit.   They
supposedly fixed this in W2K, but like the file read/memory usage issue, it
probably didn't get fixed:

http://support.microsoft.com/kb/328252

--
Tim Young
Elevate Software
www.elevatesoft.com

> Ahh, in that case the issue is simply that using UNC makes the requests go
> through the network redirector, which slows things down a bit.

But it's not a bit, it takes 10 times longer.
Does that mean that using an UNC path in EDB makes the database unusable?

Uli

Uli,

<< But it's not a bit, it takes 10 times longer.  Does that mean that using
an UNC path in EDB makes the database unusable? >>

No, it means that using a UNC path for a *local* drive is slower than using
a direct drive letter because it has to go through the network redirector.
I didn't design this Uli, Microsoft did.  We have to live with whatever they
choose to do.

Did you actually try using a UNC path for database on a different machine
and comparing to a mapped drive letter ?  There should be no difference
between the two for drives that aren't local.

--
Tim Young
Elevate Software
www.elevatesoft.com

> I didn't design this Uli, Microsoft did.  We have to live with whatever
> they choose to do.

I know

> Did you actually try using a UNC path for database on a different machine
> and comparing to a mapped drive letter ?  There should be no difference
> between the two for drives that aren't local.

I didn't try that till now.
The reason why I used the unc path is that I am storing the config-file for
all databases on one machine. Since I can switch from local to remote access
in my application, the unc-path is necessary. Though this is only necessary
for testing. Later there will be no need to use anyhting but the remote
access.

Btw: the performance even using a slow WLAN is great using the EDB-server.

Thanks. Uli

Uli,

<< The reason why I used the unc path is that I am storing the config-file
for all databases on one machine. Since I can switch from local to remote
access in my application, the unc-path is necessary. Though this is only
necessary
for testing. Later there will be no need to use anyhting but the remote
access. >>

Are you actually using a file-sharing, multi-user setup ?  If not, then you
can just use drive letters all around since you only need to specify the
path names in terms of the current machine.

<< Btw: the performance even using a slow WLAN is great using the
EDB-server. >>

Yeah, it seems that the new bi-directional caching for cursors is working
really well for remote sessions over a really slow connection.  I think I'm
going to put up an ActiveX control on the web site that demonstrates an
Internet connection and table browser with a demo ElevateDB Server running
on our server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> Are you actually using a file-sharing, multi-user setup ?  If not, then you
> can just use drive letters all around since you only need to specify the
> path names in terms of the current machine.

Yes, that's clear for me.

> Yeah, it seems that the new bi-directional caching for cursors is working
> really well for remote sessions over a really slow connection.  I think I'm
> going to put up an ActiveX control on the web site that demonstrates an
> Internet connection and table browser with a demo ElevateDB Server running
> on our server.

Great idea. Looking forward to that.

Uli