Connecting To DBF Using vfpoledb

I have the need to connect to a remote DBF table across the network.
Currently, I able to do this using a mapped drive which maps to the remote
system where the DBF is stored, as such.

Provider=vfpoledb;Data Source= \\remoteserver\dbffiles\;
Mode=ReadWrite;Collating Sequence=MACHINE;

However, mapped drives can be finicky. Now, the purpose of this post is to
ask; "Is there a better way to do this, without the need for a mapped drive?"

Fred
Wed Aug 17 10:26:59 CDT 2005

What you showed is not a mapped drive, that's a UNC name. A mapped drive is
a UNC name mapped to a drive letter.

--
Fred
Microsoft Visual FoxPro MVP


"Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
news:C26EEE53-AD1C-41FD-B679-47811B60924E@microsoft.com...
>I have the need to connect to a remote DBF table across the network.
> Currently, I able to do this using a mapped drive which maps to the remote
> system where the DBF is stored, as such.
>
> Provider=vfpoledb;Data Source= \\remoteserver\dbffiles\;
> Mode=ReadWrite;Collating Sequence=MACHINE;
>
> However, mapped drives can be finicky. Now, the purpose of this post is
> to
> ask; "Is there a better way to do this, without the need for a mapped
> drive?"

ChrisFink
Wed Aug 17 11:22:06 CDT 2005

Fred,

You are correct. So, if I use a UNC path (\\server\dbffiles), instead of a
mapped drive (t:\dbffiles) a mapped drive will not be needed; I will not have
to make a connection of the UNC path to a physical drive, I can just
reference the UNC path in my connection string? Is this correct? Ifso, I
guess this is the solution to my problem.




"Fred Taylor" wrote:

> What you showed is not a mapped drive, that's a UNC name. A mapped drive is
> a UNC name mapped to a drive letter.
>
> --
> Fred
> Microsoft Visual FoxPro MVP
>
>
> "Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
> news:C26EEE53-AD1C-41FD-B679-47811B60924E@microsoft.com...
> >I have the need to connect to a remote DBF table across the network.
> > Currently, I able to do this using a mapped drive which maps to the remote
> > system where the DBF is stored, as such.
> >
> > Provider=vfpoledb;Data Source= \\remoteserver\dbffiles\;
> > Mode=ReadWrite;Collating Sequence=MACHINE;
> >
> > However, mapped drives can be finicky. Now, the purpose of this post is
> > to
> > ask; "Is there a better way to do this, without the need for a mapped
> > drive?"
>
>
>

Paul
Wed Aug 17 14:43:33 CDT 2005

Along these lines, a few years ago I found connecting to free tables via a
UNC path to be *much* slower than connecting to the same tables via a mapped
drive. (I say connecting to, because once the table was opened, data access
seemed quick enough.)

Was it just me? If not, has the problem been fixed? I haven't tried any such
comparisons recently.



"Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
news:480AFD44-CD61-444B-B61F-E707359CA0F7@microsoft.com...
> Fred,
>
> You are correct. So, if I use a UNC path (\\server\dbffiles), instead of
> a
> mapped drive (t:\dbffiles) a mapped drive will not be needed; I will not
> have
> to make a connection of the UNC path to a physical drive, I can just
> reference the UNC path in my connection string? Is this correct? Ifso, I
> guess this is the solution to my problem.
>
>
>
>
> "Fred Taylor" wrote:
>
>> What you showed is not a mapped drive, that's a UNC name. A mapped drive
>> is
>> a UNC name mapped to a drive letter.
>>
>> --
>> Fred
>> Microsoft Visual FoxPro MVP
>>
>>
>> "Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
>> news:C26EEE53-AD1C-41FD-B679-47811B60924E@microsoft.com...
>> >I have the need to connect to a remote DBF table across the network.
>> > Currently, I able to do this using a mapped drive which maps to the
>> > remote
>> > system where the DBF is stored, as such.
>> >
>> > Provider=vfpoledb;Data Source= \\remoteserver\dbffiles\;
>> > Mode=ReadWrite;Collating Sequence=MACHINE;
>> >
>> > However, mapped drives can be finicky. Now, the purpose of this post
>> > is
>> > to
>> > ask; "Is there a better way to do this, without the need for a mapped
>> > drive?"
>>
>>
>>

Fred
Wed Aug 17 20:31:05 CDT 2005

That may have been a problem in earlier versions of VFP (like 5), but I've
never considered it or noticed it as a problem in later versions.

--
Fred
Microsoft Visual FoxPro MVP


"Paul Pedersen" <no-reply@swen.com> wrote in message
news:eOfA3P2oFHA.2916@TK2MSFTNGP14.phx.gbl...
> Along these lines, a few years ago I found connecting to free tables via a
> UNC path to be *much* slower than connecting to the same tables via a
> mapped drive. (I say connecting to, because once the table was opened,
> data access seemed quick enough.)
>
> Was it just me? If not, has the problem been fixed? I haven't tried any
> such comparisons recently.
>
>
>
> "Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
> news:480AFD44-CD61-444B-B61F-E707359CA0F7@microsoft.com...
>> Fred,
>>
>> You are correct. So, if I use a UNC path (\\server\dbffiles), instead of
>> a
>> mapped drive (t:\dbffiles) a mapped drive will not be needed; I will not
>> have
>> to make a connection of the UNC path to a physical drive, I can just
>> reference the UNC path in my connection string? Is this correct? Ifso,
>> I
>> guess this is the solution to my problem.
>>
>>
>>
>>
>> "Fred Taylor" wrote:
>>
>>> What you showed is not a mapped drive, that's a UNC name. A mapped
>>> drive is
>>> a UNC name mapped to a drive letter.
>>>
>>> --
>>> Fred
>>> Microsoft Visual FoxPro MVP
>>>
>>>
>>> "Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
>>> news:C26EEE53-AD1C-41FD-B679-47811B60924E@microsoft.com...
>>> >I have the need to connect to a remote DBF table across the network.
>>> > Currently, I able to do this using a mapped drive which maps to the
>>> > remote
>>> > system where the DBF is stored, as such.
>>> >
>>> > Provider=vfpoledb;Data Source= \\remoteserver\dbffiles\;
>>> > Mode=ReadWrite;Collating Sequence=MACHINE;
>>> >
>>> > However, mapped drives can be finicky. Now, the purpose of this post
>>> > is
>>> > to
>>> > ask; "Is there a better way to do this, without the need for a mapped
>>> > drive?"
>>>
>>>
>>>
>
>