btrieve with IDS (Version9.x)

[Database Administrator]

Hi,

i have a native btrieve-application, which specifies the complete
paths to the (btrieve) data-base files explicit. Therefore the
directory containing the data-files has to be mapped to a local drive
letter on the clients via a "release".
Unfortunately btrieve needs write - rights on that mapped drive,
allthough the client itself never changes the files: the requests to
update or create are send to the server-engine on the server! And the
engine changes the files!
So one can imaagine, that it shoubd be possible to omit write-rights
to the datafiles on windows-system-level, but the btrieve-server,
which runs on the server with more rights, should be able to change
the files.

Unfortunatley this semms impossible.

So I wonder, if one can avoid mapping using IDS:

The documentation of IDS is staggering poor! So I made some experiments:

The datafiles are at d:\project\data ("d:" is a local drive on the
server). The server has IP-Adress "x.y.z.u".

So I switched "Use IDS" on the Server-engine to "ON" and put to the
idshost-file

#############
# j: www.pe.com # Drive mapping
z: x.y.z.u
#############

The drive z: is not mapped on the client!

If I open a file z:\\project\data\test.dat within the application, I
get the error 172: Database name not found.

OK, but using btrieve I dont have any Database name!

I turn "trace operation" to ON and select OPEN(0). In the LOG-File I get

File: "btrv://x.y.z.u/www.pe.com?dbfile=project%5Cdata%5Ctest.dat"

This is strange, because, the line in idshost where the www.pe.com is
mentioned, is commented out (line starts with #)!

If I change the line say to

#############
# j: www.peXYZ.com # Drive mapping
z: x.y.z.u
#############

I get in the log:

File:
"btrv://x.y.z.u/www.peXYZ.com?dbfile=project%5Cdata%5Ctest.dat"

This is also so, if I put


#############
# j: www.peXYZ.com # Drive mapping
###
###
###
z: x.y.z.u
#############


to idshost.
If idshost contains only the line

z: x.y.z.u

I get:

File: "btrv://x.y.z.u/%c2%92%7C?dbfile=project%5Cdata%5Ctest.dat"

If I use

#############
# j: www.peXYZ.com # Drive mapping
z: x.y.z.u abcdef
#############

then I get (as expected

File: "btrv://x.y.z.u/abcdef?dbfile=project%5Cdata%5Ctest.dat"


If I do not use idshost, the logfile looks like (d$ is mapped on the
client as "F:"):

File: "\\mycomputer\D$\project\data\test.dat"

without "btrv:" and so on (and nothing about the local
"drive" "F:"!)


How can I avoid the "dbfile=" construction in the ids-replacement?

I would expect somthing like

z: x.y.z.u/D$

in the idshost-file, but doing so, I get a status-code 3103 (the
server is running!).


I suppose, that I do something wrong here. Any idea, how to make it
correct, would be welcome!
Thanks in advance!

Mircea

[Database Administrator]

The "database" parameter allows you to specify which database you are
accessing. Normally used by SQL only, the use of this paramerter in IDS
is also important.

You can test it with this IDS line:
Z:\DEMO servername DEMODATA

Then, open the file: "Z:\DEMO\PERSON.MKD" and you'll find the file in
the DEMODATA database (C:\PVSW\DEMODATA) gets opened correctly.

For your own application, you should specify the database as well, so
that the base location can be found. If the files are being opened via
the Z:\PROJECT\DATA directory, and if your database (i.e. DDF files) is
in Z:\PROJECT\DATA, then the line will look like this:

Z:\PROJECT\DATA\ servername databasename

Try to avoid using the IP address, which connects more slowly.


BTW, this by itself may not work around the rights issue. The
Client/Server database engine enforces the OS rights of the user. As
such, if the user has WRITE rights, then he or she will be able to write
to the database. This is the way Btrieve security was designed long ago.

Using IDS like this will enable you to "Hide" the share, but users will
still have the needed rights. If you want to remove OS-level rights
entirely, then you'll need to set up the "advanced Btrieve security" for
this database. This is a LOT more complicated, and I strongly encourage
you to set up a test environment to play with this, first, since you can
actually make the system unusable if you're not careful with this one.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@goldstarsoftware.com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


nmm wrote:
> Hi,
>
> i have a native btrieve-application, which specifies the complete
> paths to the (btrieve) data-base files explicit. Therefore the
> directory containing the data-files has to be mapped to a local drive
> letter on the clients via a "release".
> Unfortunately btrieve needs write - rights on that mapped drive,
> allthough the client itself never changes the files: the requests to
> update or create are send to the server-engine on the server! And the
> engine changes the files!
> So one can imaagine, that it shoubd be possible to omit write-rights
> to the datafiles on windows-system-level, but the btrieve-server,
> which runs on the server with more rights, should be able to change
> the files.
>
> Unfortunatley this semms impossible.
>
> So I wonder, if one can avoid mapping using IDS:
>
> The documentation of IDS is staggering poor! So I made some experiments:
>
> The datafiles are at d:\project\data ("d:" is a local drive on the
> server). The server has IP-Adress "x.y.z.u".
>
> So I switched "Use IDS" on the Server-engine to "ON" and put to the
> idshost-file
>
> #############
> # j: www.pe.com # Drive mapping
> z: x.y.z.u
> #############
>
> The drive z: is not mapped on the client!
>
> If I open a file z:\\project\data\test.dat within the application, I
> get the error 172: Database name not found.
>
> OK, but using btrieve I dont have any Database name!
>
> I turn "trace operation" to ON and select OPEN(0). In the LOG-File I get
>
> File: "btrv://x.y.z.u/www.pe.com?dbfile=project%5Cdata%5Ctest.dat"
>
> This is strange, because, the line in idshost where the www.pe.com is
> mentioned, is commented out (line starts with #)!
>
> If I change the line say to
>
> #############
> # j: www.peXYZ.com # Drive mapping
> z: x.y.z.u
> #############
>
> I get in the log:
>
> File:
> "btrv://x.y.z.u/www.peXYZ.com?dbfile=project%5Cdata%5Ctest.dat"
>
> This is also so, if I put
>
>
> #############
> # j: www.peXYZ.com # Drive mapping
> ###
> ###
> ###
> z: x.y.z.u
> #############
>
>
> to idshost.
> If idshost contains only the line
>
> z: x.y.z.u
>
> I get:
>
> File: "btrv://x.y.z.u/%c2%92%7C?dbfile=project%5Cdata%5Ctest.dat"
>
> If I use
>
> #############
> # j: www.peXYZ.com # Drive mapping
> z: x.y.z.u abcdef
> #############
>
> then I get (as expected
>
> File: "btrv://x.y.z.u/abcdef?dbfile=project%5Cdata%5Ctest.dat"
>
>
> If I do not use idshost, the logfile looks like (d$ is mapped on the
> client as "F:"):
>
> File: "\\mycomputer\D$\project\data\test.dat"
>
> without "btrv:" and so on (and nothing about the local
> "drive" "F:"!)
>
>
> How can I avoid the "dbfile=" construction in the ids-replacement?
>
> I would expect somthing like
>
> z: x.y.z.u/D$
>
> in the idshost-file, but doing so, I get a status-code 3103 (the
> server is running!).
>
>
> I suppose, that I do something wrong here. Any idea, how to make it
> correct, would be welcome!
> Thanks in advance!
>
> Mircea
>
>
>

[Database Administrator]

Thank you for these interesting remarks!

What you mean with the "advanced Btrieve security" is what they call
"Database Security Model". I will try
"Setting Up Btrieve Security"
().

Regards
Mircea


BtrieveBill schrieb:
> The "database" parameter allows you to specify which database you are
> accessing. Normally used by SQL only, the use of this paramerter in IDS
> is also important.
>
> You can test it with this IDS line:
> Z:\DEMO servername DEMODATA
>
> Then, open the file: "Z:\DEMO\PERSON.MKD" and you'll find the file in
> the DEMODATA database (C:\PVSW\DEMODATA) gets opened correctly.
>
> For your own application, you should specify the database as well, so
> that the base location can be found. If the files are being opened via
> the Z:\PROJECT\DATA directory, and if your database (i.e. DDF files) is
> in Z:\PROJECT\DATA, then the line will look like this:
>
> Z:\PROJECT\DATA\ servername databasename
>
> Try to avoid using the IP address, which connects more slowly.
>
>
> BTW, this by itself may not work around the rights issue. The
> Client/Server database engine enforces the OS rights of the user. As
> such, if the user has WRITE rights, then he or she will be able to write
> to the database. This is the way Btrieve security was designed long ago.
>
> Using IDS like this will enable you to "Hide" the share, but users will
> still have the needed rights. If you want to remove OS-level rights
> entirely, then you'll need to set up the "advanced Btrieve security" for
> this database. This is a LOT more complicated, and I strongly encourage
> you to set up a test environment to play with this, first, since you can
> actually make the system unusable if you're not careful with this one.
> Goldstar Software Inc.
> Pervasive-based Products, Training & Services
> Bill Bach
> BillBach@goldstarsoftware.com
> http://www.goldstarsoftware.com
> *** Next Pervasive Service & Support Class - Nov 2008 ***
>
>
> nmm wrote:
>> Hi,
>>
>> i have a native btrieve-application, which specifies the complete
>> paths to the (btrieve) data-base files explicit. Therefore the
>> directory containing the data-files has to be mapped to a local drive
>> letter on the clients via a "release".
>> Unfortunately btrieve needs write - rights on that mapped drive,
>> allthough the client itself never changes the files: the requests to
>> update or create are send to the server-engine on the server! And the
>> engine changes the files!
>> So one can imaagine, that it shoubd be possible to omit write-rights
>> to the datafiles on windows-system-level, but the btrieve-server,
>> which runs on the server with more rights, should be able to change
>> the files.
>>
>> Unfortunatley this semms impossible.
>>
>> So I wonder, if one can avoid mapping using IDS:
>>
>> The documentation of IDS is staggering poor! So I made some experiments:
>>
>> The datafiles are at d:\project\data ("d:" is a local drive on the
>> server). The server has IP-Adress "x.y.z.u".
>>
>> So I switched "Use IDS" on the Server-engine to "ON" and put to the
>> idshost-file
>>
>> #############
>> # j: www.pe.com # Drive mapping
>> z: x.y.z.u
>> #############
>>
>> The drive z: is not mapped on the client!
>>
>> If I open a file z:\\project\data\test.dat within the application, I
>> get the error 172: Database name not found.
>>
>> OK, but using btrieve I dont have any Database name!
>>
>> I turn "trace operation" to ON and select OPEN(0). In the LOG-File I get
>>
>> File: "btrv://x.y.z.u/www.pe.com?dbfile=project%5Cdata%5Ctest.dat"
>>
>> This is strange, because, the line in idshost where the www.pe.com is
>> mentioned, is commented out (line starts with #)!
>>
>> If I change the line say to
>>
>> #############
>> # j: www.peXYZ.com # Drive mapping
>> z: x.y.z.u
>> #############
>>
>> I get in the log:
>>
>> File:
>> "btrv://x.y.z.u/www.peXYZ.com?dbfile=project%5Cdata%5Ctest.dat"
>>
>> This is also so, if I put
>>
>>
>> #############
>> # j: www.peXYZ.com # Drive mapping
>> ###
>> ###
>> ###
>> z: x.y.z.u
>> #############
>>
>>
>> to idshost.
>> If idshost contains only the line
>>
>> z: x.y.z.u
>>
>> I get:
>>
>> File: "btrv://x.y.z.u/%c2%92%7C?dbfile=project%5Cdata%5Ctest.dat"
>>
>> If I use
>>
>> #############
>> # j: www.peXYZ.com # Drive mapping
>> z: x.y.z.u abcdef
>> #############
>>
>> then I get (as expected
>>
>> File: "btrv://x.y.z.u/abcdef?dbfile=project%5Cdata%5Ctest.dat"
>>
>>
>> If I do not use idshost, the logfile looks like (d$ is mapped on the
>> client as "F:"):
>>
>> File: "\\mycomputer\D$\project\data\test.dat"
>>
>> without "btrv:" and so on (and nothing about the local
>> "drive" "F:"!)
>>
>>
>> How can I avoid the "dbfile=" construction in the ids-replacement?
>>
>> I would expect somthing like
>>
>> z: x.y.z.u/D$
>>
>> in the idshost-file, but doing so, I get a status-code 3103 (the
>> server is running!).
>>
>>
>> I suppose, that I do something wrong here. Any idea, how to make it
>> correct, would be welcome!
>> Thanks in advance!
>>
>> Mircea
>>
>>
>>

[Database Administrator]

That's the one.
BB

nmm wrote:
> Thank you for these interesting remarks!
>
> What you mean with the "advanced Btrieve security" is what they call
> "Database Security Model". I will try
> "Setting Up Btrieve Security"
> ().
>
> Regards
> Mircea
>
>
> BtrieveBill schrieb:
>> The "database" parameter allows you to specify which database you are
>> accessing. Normally used by SQL only, the use of this paramerter in IDS
>> is also important.
>>
>> You can test it with this IDS line:
>> Z:\DEMO servername DEMODATA
>>
>> Then, open the file: "Z:\DEMO\PERSON.MKD" and you'll find the file in
>> the DEMODATA database (C:\PVSW\DEMODATA) gets opened correctly.
>>
>> For your own application, you should specify the database as well, so
>> that the base location can be found. If the files are being opened via
>> the Z:\PROJECT\DATA directory, and if your database (i.e. DDF files) is
>> in Z:\PROJECT\DATA, then the line will look like this:
>>
>> Z:\PROJECT\DATA\ servername databasename
>>
>> Try to avoid using the IP address, which connects more slowly.
>>
>>
>> BTW, this by itself may not work around the rights issue. The
>> Client/Server database engine enforces the OS rights of the user. As
>> such, if the user has WRITE rights, then he or she will be able to write
>> to the database. This is the way Btrieve security was designed long ago.
>>
>> Using IDS like this will enable you to "Hide" the share, but users will
>> still have the needed rights. If you want to remove OS-level rights
>> entirely, then you'll need to set up the "advanced Btrieve security" for
>> this database. This is a LOT more complicated, and I strongly encourage
>> you to set up a test environment to play with this, first, since you can
>> actually make the system unusable if you're not careful with this one.
>> Goldstar Software Inc.
>> Pervasive-based Products, Training & Services
>> Bill Bach
>> BillBach@goldstarsoftware.com
>> http://www.goldstarsoftware.com
>> *** Next Pervasive Service & Support Class - Nov 2008 ***
>>
>>
>> nmm wrote:
>>> Hi,
>>>
>>> i have a native btrieve-application, which specifies the complete
>>> paths to the (btrieve) data-base files explicit. Therefore the
>>> directory containing the data-files has to be mapped to a local drive
>>> letter on the clients via a "release".
>>> Unfortunately btrieve needs write - rights on that mapped drive,
>>> allthough the client itself never changes the files: the requests to
>>> update or create are send to the server-engine on the server! And the
>>> engine changes the files!
>>> So one can imaagine, that it shoubd be possible to omit write-rights
>>> to the datafiles on windows-system-level, but the btrieve-server,
>>> which runs on the server with more rights, should be able to change
>>> the files.
>>>
>>> Unfortunatley this semms impossible.
>>>
>>> So I wonder, if one can avoid mapping using IDS:
>>>
>>> The documentation of IDS is staggering poor! So I made some experiments:
>>>
>>> The datafiles are at d:\project\data ("d:" is a local drive on the
>>> server). The server has IP-Adress "x.y.z.u".
>>>
>>> So I switched "Use IDS" on the Server-engine to "ON" and put to the
>>> idshost-file
>>>
>>> #############
>>> # j: www.pe.com # Drive mapping
>>> z: x.y.z.u
>>> #############
>>>
>>> The drive z: is not mapped on the client!
>>>
>>> If I open a file z:\\project\data\test.dat within the application, I
>>> get the error 172: Database name not found.
>>>
>>> OK, but using btrieve I dont have any Database name!
>>>
>>> I turn "trace operation" to ON and select OPEN(0). In the LOG-File I get
>>>
>>> File: "btrv://x.y.z.u/www.pe.com?dbfile=project%5Cdata%5Ctest.dat"
>>>
>>> This is strange, because, the line in idshost where the www.pe.com is
>>> mentioned, is commented out (line starts with #)!
>>>
>>> If I change the line say to
>>>
>>> #############
>>> # j: www.peXYZ.com # Drive mapping
>>> z: x.y.z.u
>>> #############
>>>
>>> I get in the log:
>>>
>>> File:
>>> "btrv://x.y.z.u/www.peXYZ.com?dbfile=project%5Cdata%5Ctest.dat"
>>>
>>> This is also so, if I put
>>>
>>>
>>> #############
>>> # j: www.peXYZ.com # Drive mapping
>>> ###
>>> ###
>>> ###
>>> z: x.y.z.u
>>> #############
>>>
>>>
>>> to idshost.
>>> If idshost contains only the line
>>>
>>> z: x.y.z.u
>>>
>>> I get:
>>>
>>> File: "btrv://x.y.z.u/%c2%92%7C?dbfile=project%5Cdata%5Ctest.dat"
>>>
>>> If I use
>>>
>>> #############
>>> # j: www.peXYZ.com # Drive mapping
>>> z: x.y.z.u abcdef
>>> #############
>>>
>>> then I get (as expected
>>>
>>> File: "btrv://x.y.z.u/abcdef?dbfile=project%5Cdata%5Ctest.dat"
>>>
>>>
>>> If I do not use idshost, the logfile looks like (d$ is mapped on the
>>> client as "F:"):
>>>
>>> File: "\\mycomputer\D$\project\data\test.dat"
>>>
>>> without "btrv:" and so on (and nothing about the local
>>> "drive" "F:"!)
>>>
>>>
>>> How can I avoid the "dbfile=" construction in the ids-replacement?
>>>
>>> I would expect somthing like
>>>
>>> z: x.y.z.u/D$
>>>
>>> in the idshost-file, but doing so, I get a status-code 3103 (the
>>> server is running!).
>>>
>>>
>>> I suppose, that I do something wrong here. Any idea, how to make it
>>> correct, would be welcome!
>>> Thanks in advance!
>>>
>>> Mircea
>>>
>>>
>>>