I had a look at I*net dataserver a long time ago, but for various
reasons I am now taking a new look.

I have downloaded the sdk which has a single-user version of i*net.

I have set up a server V8 and a client.

I have set up a couple of routers in between the 2 machines so that
there is no simple connection between server and client. All pings ok

If I connect using pids: etc it all connects no problem.

I am using the function executer with the V8 client.

If I try to use the idshosts file, nothing works.

I have read and reread the docs for idshosts and can't seem to see
what I am doing wrong.

I have copied the file to all the obvious places. winnt, winnt\system,
winnt\system32, PVSW\bin just to be sure.

I am using the sample.btr file.

I have set up a database set which points to the location -
c:\pvsw\samples

If I use UNC I put in \\test2000-svr\c\pvsw\samples IP jah

jah is the database set. I use the IP address to redirect. I have set
up permissions for the user name and password.

I have set the user and password in the config options.

c is the share name on the server - sorry about that. I didn't do it.

In the function executor I put
\\test2000-svr\c\pvsw\samples\sample.btr

The result is that the local engine can't find the file

I can't see any real way to confirm that it has looked at the idshosts
file and not found a match and so has tried to find it on a server and
then a local engine.

I think this is where I got to last time but then had to move on to
something else. But the old I*net with psql7 did let you know if it
was using ids if you ran the install and smart scout tests.

I am hoping that some kind soul will point me in the right direction.

Thanks for any help.

John Aherne

I believe that the IDSHOSTS file MUST have a trailing backslash. An
example from my server is:
M:\PVSW\ www2.goldstarsoftware.com PVSW

The newer versions of IDS need the IDSHOSTS file in the C:\PVSW\BIN
directory. Be sure, of course, that the "USE IDS" setting is set to YES.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: November 16-19, 2004: See our web site for details!



John Aherne wrote:

Bill

Thanks for the reply. Saved me more head-banging time.

I added on the final \ on my unc line and that worked.

When it opens the file I check with monitor and the only user in is
called 'system'. The username in the config file is jah. This does not
seem quite right.

The psqlids.log file shows the following:--

Connect TCP unavailable

Login accepted username password ( correct ones used - jah jah)

Disconnect TCP jah

But monitor shows system.

My mapped drive option still does not work. The message I get says:-
'File does not appear to exist'

It implies that it can't find the f: drive.

My idshosts line is:--

f:\pvsw\samples\ IP jah

There is no mapping anywhere for the f: drive. So that makes sense if
it is not looking in the idshosts file or not finding a match, which
seems the more likely event.

Thanks for any pointers.

John Aherne



Bill Bach <bbach (AT) cncdsl (DOT) com> wrote

You may or may not know this but IDS is rather long in the tooth.
It also has more than a couple of limitations.
It provides no real enhanced functionality over Pervasive.SQL 8.5+ as
the Pervasive.SQL client can now natively connect over pure TCP/IP
network sessions and allow a user to have different database level
rights than OS level rights to the files.

Ok, ok, it does provide compression where the Pervasive.SQL requester
does not however...
It does not provide encryption (if that is important to you) like the
Pervasive client can, nor does it handle the Btrieve API "chunk"
calls.

So the long and short of it is that unless you have to have
compression and can give up the other features then I would not use
it.

I have also heard that since the functionality has been replaced it is
being pulled from the next version of the product so I would not do
any new development on it. I would instead use the URI connection
string and database security.

Aside from all that, yes the Pervasive monitor will more than likely
show whatever account the IDS service is logged in as for the client
username unless you turn on IDS security. Even then I don't think it
will show up as the user, but will enforce the users configured
rights.

Leonard

On 9 Nov 2004 08:06:55 -0800, johnaherne (AT) rocs (DOT) co.uk (John Aherne)
wrote:

John Aherne wrote:

This is a message generated by WBEXEC32 (Function Executor). For some reason, this app
decides to check for the file first and displays this warning. If you use WBEXEC (the
16-bit version), then you'll see what your application will see -- it works with no
warning message.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: November 16-19, 2004: See our web site for details!

I have to agree with Leonard about the IDS not really being a
supported product. I've used it for a couple of years on our network
to prevent users from being able to access the data directories. I'm
using the ActiveX controls with VB6 and for that purpose it works
well. But it does slow down the performance quite a bit. I went to
using the extended calls for any reporting to speed things up. But
I've just recently discontinued it's use. We moved to a new server
and it would unload itself. We set it up to restart itself but since
it is not really a supported product I don't expect any of the
problems to be really resolved which is why I decided to just go the
the UNC path in the ActiveX controls and not map any drives provideing
at least a little security from users doing something by accident.

Gil

Leonard <lharvey (AT) austin (DOT) rr.com> wrote

Everyone

Thanks for the information.

If ids is going to be pulled fairly soon and is not a supported
product, then I think I will be better looking for a different
solution to the problem.

It was useful to revisit the product and get an update on what people
were doing.

Once again, thanks.

Regards

John Aherne




Bill Bach <bbach (AT) cncdsl (DOT) com> wrote