I am thiinking that a complete review of the environment may be in
order. It sounds like things went well on the install, but the NetWare
engine is either not properly responding, or the app is doing some
other strange things to you.
In short, you need the PSQL engine installed properly on the server.
Test this by running WBEXEC32 (Function Executor) on the workstation
and attempting to open the following file (with File/Open):
KSSERVER1\SYS:PVSW\DEMODATA\PERSON.MKD
If this file opens correctly, then use the Pervasive Monitor tool to
connect to the KSSERVER1 server and verify that the Microkernel/Active
Users screen shows your username active with the file open.
If Monitor does NOT show the active connection, then close the local
WGE on your workstation and try again.
If the file does work...
Eeeewww -- Just thinking about the possibilities, this will be endless
if I try to list EVERY combination of working/non-working components.
This is a case whereby a sup****t visit may make a lot more sense for a
faster resolution.
Let's stick with one item at a time, and see how it goes. Please try
the above and let me know if the File/Open works. If not, what is the
error message. Also, let me know the status of the Monitor display.
Can you connect to the server via Monitor? Can you see the active user
on the server?
Once we get that, we'll work from there. Also, in the meantime, run
"MODULES NWMK*" from the server and verify that the NWMKDE.NLM is
Version 9.5.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@[EMAIL PROTECTED]
Chicago: Pervasive Service & Sup****t Class - 08/28/2007***
Cliff Wiernik wrote:
> Upgraded at a customer DacEasy from version 13 to Version 15. This
> version uses PSQL v9.5 instead of the previous 7.94. Network in WinXP
> workstations with netware 6.5sp5. On a test server, I tried the
> upgrade with the trial version of netware server PSQL9.5, which
> appeared to work but alas, I did not test it thorough enough.
>
> DacEasy only provides the 9.50.077 workgroup version. Thus, I
> purchased a PSQL upgrade for the netware server.
>
> When I did the upgrade I did the following:
>
> 1. Loaded the netware server PSQL v9.5. No appararent issues with
> that and Computer Associates Arcserve works just fine with this
> version.
>
> 2. Changed the gateway located file on the g: drive in the data
> directory, ~pvsw~.loc to ksserver1 from workstation1.
>
> 3. Upgraded the software on first workstation and all worked fine.
>
> 4. Went to second workstation and experienced problems. The software
> said the data directory had files missing or that the files were
> controlled by another gateway. I had to resort to changing the
> ~pvsw~.loc file back to workstation1 and then I could upgrade and add
> the remaining workstations.
>
> 5. It appears that after I had all workstations upgraded, I could
> change the ~pvsw~.loc file back to ksserver1 and then that appeared
> to work. I don't know if it was actually using the netware server to
> manage the data. However, since I did not want to take a chance, I
> reset the ~pvsw~.loc back to the workstation1 setting and that
> workstation is currently acting as the gateway. The data still
> resides on the g: drive of the netware server with the netware server
> edition of PSQL 9.5 loaded.
>
> 6. Daceasy software has a process to integrate Crystal Re****ts with
> that automatically creates the DSN in the format DEBC xxxxx where
> xxxxx is the profile name. If I tried to put that file, the profile
> file, on the G: drive with Data on the G: drive, then when it tries
> to connect to the DSN via the program or via ODBC Configuration;test,
> I would get the following error:
>
> [Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine
> Inteface][Data Record Manager] No such table or object. I also got
> this error from DSN;configuration;test
>
> This also happened if I tested on a WinXP Workgroup network with the
> workgroup engine loaded on both machines. If I instead put saved the
> profile on the local workstation drive with the data still saved on
> the remote drive (WinXP Workgroup network), then this worked without
> the generating an error. The Crystal Re****ts connection and a
> connection I established via SQL to the ODBC in the XBase++ program
> language worked properly
>
> 7. I then attempted the same scenario on the Netware network. Data
> on the G drive, Netware Server PSQL 9.5 loaded on the Netware 6.5sp5
> server. That appeared to work just fine and the
> ODBC;configuration;test process re****ted a successful connection.
>
> The name of the ODBC connection is: DEBC KStone
>
> However, when I tried to start Crystal Re****ts through the DacEasy
> Business Center process, it generated the following error:
>
> [ODBC Error][Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC
> Engine Interface][Data Record Manager] The specified filename is
> invalid (btrieve error 11). The ODBC;configuration;test process did
> work at this point and indicated a successful connection. At this
> point the ~pvsw~.loc file was pointing to the workstation1 computer.
>
> I then thought it might be just a crystal re****t problem so I tried to
> access the data via my Xbase++ SQL library. When I tried the
> connection I recevied the follwing SQL error:
>
> DB Access:[PervasIve][ODBC Client Interface][LNA][Pervasive][ODBC
> Engine Interface] Unable to open table: OEORDERS [Pervasive][ODBC
> Client Interface][LNA][Pervasive][ODBC Engine Inteface][Data Record
> Manager]You are not authorized to perform this operation.
>
> I then tried to access the data with the LiveWare Public R&R Infinity
> Re****t Writer-SQL edition. It generated the same identical "you are
> not authorized..." error.
>
> I also went into the PCC and tried to access any of the DacEasy files
> for the ODBC connection. It also generated teh "you are not
> authorized to perform this operation" error.
>
> 8. I then changed the ~pvsw~.loc file to ksserver1 again, restarted
> the server with load nss and mount all prior to the bstart and put
> mgrstart at the end of autoexec.ncf. Then, even the direct access of
> the DacEasy accounting data, not through ODBC, would not work, saying
> that the files were missing.
>
> At this point I am at a loss as to why this will not work with the
> netware server. It appears that I may have wasted the cost of
> upgrading the netware software and should have just got a windows
> server so I could use the workgroup engines by themselves. Even on
> my test server, it now is behaving this way and I could not make even
> the direct access appear to work.
>
> What do I need to do to make this work. Reading the do***entation
> seems to imply that it should work but something appears to not be
> configured properly.
>
> Cliff
--
|
