Error getting DNS name when starting PWE 2

[62chev]

We are running Progression 7.6.200.5 (Feb patch) on a Novell server (5.1 sp7), pervasive 2000i SP4 with Windows XP clients (running Novell Client 4.83 sp3) TCP/IP.

When logging in through PWE, we receive the error message - An error occurred while getting the DSN name. We are able to accept this and go on but none of the predefined crystal reports will execute. When attempting to run a crystal report from within Progression the following error is generated:

Error Occurred in RunMR2KReport
-2147024809
Error 524 in ERSRecSet.ConnectString:
Unable to connect to the database. Check you connection string.

Errors are also logged to the pvsw.log:

Error 8505 an initialization error occurred when trying to establish a session with the WSE.
Error 8517 an error occurred when closing the session with WSE.

The only reference to these errors I could locate is Pervsaive documentation saying these errors indicate an attempt to use a local workstation engine to read that data files. It suggested setting the target engine to server only in the PCC. I did this and it didn't help.

Other things I have done.
I was using Novel Client 4.9, one tek tip suggested going back to 4.83 (no change)

Added the server and tcp/ip address to the lmhosts file on client.

I can sucessfully ping the server by name.

Several tips on Progressions's Infomine discuss this error. They include reinstalling Pervsavie, confirming permissions, rights to registry keys, deleting ODBC connections etc. etc. etc.

I have tried each of these. My understand (although somewhat limited since I am totally new to the progression, pervasive, novell environment) is the data sources are established automatically and no longer needed to be manually setup in the ODBC Data Source Administrator.

I removed all defined data sources with no luck, I also created data sources for each of the companies defined in Progression also with no luck. It is not clear in the informine articles what the proper naming convention/configuration is for the ODBC data sources.

If someone is successfully operating in this environment and would be willing to share how their ODBC drivers are defined or other things they ran into I would be very gratefull.

I also ran the Pervasive system analyzer (both 2000i and 8.50) to see if it would detect any problems.

Both report an error when resolving the target server address. Ultimately they both resolve our server name to the proper IP address.

The result of testing communication TCPIP with PSA (2000i):

Information : IDSHOSTS entry :
Information : Target does not appear to be IDS.
Warning : NWDSReadObjectInfo : object F : status : fffffda7 (-601)
Information : Calling NetWare API to parse input target.
Information : Target server name SI_FS1
Information : Fully qualified name SI_FS1\SYS:\PVSW
Friday, March 12, 2004, 14:35 ---Step 3 : Resolve full target name into a network address.Information : Using NetWare API to query Novell Directory Services
Information : Target engine SPX address : 03E0E408:000000000001:8059
Information : Checking DNS for TCP/IP address of SI_FS1.
Warning : getservbyname failed : 11004
Warning : Using Btrieve default port : 3351
Information : Target engine TCP address : 10.0.0.5:3351

The result of testing communication TCPIP with PSA (8.50):

*** Establishing connection using TCP/IP protocol...

Target machine name : si_fs1
Resolving target name to TCP network address...
Trying to use named pipe request to resolve name to address...
Unable to resolve name to address via named piped request. CallNamedPipe function returned status 67.
Trying to use Domain Name Server to resolve name to address...
Successfully resolved target name to address.
Target TCP address is 10.0.0.5:3351.
Attempting to connect via WinSock TCP/IP...
Successfully connected to 10.0.0.5 via TCP/IP protocol.

I don't know if these errors are relevant or not, but my hunch is PWE is possibly using one of these name resolution methods and is failing. Other posts have indicated PWE is 'hard coded' to look for specific name DSN's etc - again since I'm not sure exactly the syntax or configuration expected I am at a loss.

Since I am new to Progression I am curious what others would recommend regarding support. I spoke with Progression about tech support and they said they offer it but most go through a reseller.

I would be interested in feedback from users that are getting their support directly with Progression and their opinion of it as well as using reseller support. I am open to going either direction but would like feedback before making a decision.

Appreciate any help and/or feedback anyone can provide.

Thank you!

Jim

 

[dgillz]

after you imstalledthe macola client on the workstation, did you reboot the workstation as indicated? If not this error can result.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[62chev]

Thanks for the response, yes I did reboot after installing client and after reinstalling it (several times).

I am trying to get an idea from Macola what command PWE is actually issuing. My understanding is getting any 'technical' help from Macola support can be a challenge.

Thanks for the suggestion.

Jim

 

[dgillz]

If you look under control panel, admin tools, ODBC data sources, can you see the DSNs there?

Also, there is a rather lengthy infomine document on what can cause this error. There are several possible causes. Have oyu seen this document?

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[stravis]

I would not suggest getting support directly from Progression unless you have an individual on staff with a strong understanding of the business implications of changes made in Macola. The advantage of using a "good" reseller, is that they have an understanding of both the business and technical aspects of Macola, and most importantly they are not influenced by a corporate entity that would keep them from speaking frankly and honestly about the product. For example, Macola will tell you install our new update, we tested it, it works. A Macola Reseller will tell you, let someone else be on the bleeding edge, then when we know everything is Kosher, let's install this "new" (several months old) update. Let me tell you, this can mean a world of difference.

As to your problem, I would suggest that you attempt to create a Pervasive ODBC connection to the database and see if you are able to do so from the client, logged in as the problem user. If I am correct, I think your problem lies here, and you can use Pervasive tech documents to resolve.

Scott Travis
infoSpring, LLC.

 

[MacolaHelp]

Jim: it sounds like your pervasive is looking for a workstation engine instead of a server engine. Can we review your client settings? It appears that pvsw is trying to resolve both spx & tcp/ip right now. You should be able to do tcpip exclusively with nw5 & > as it is native. If you want, we can do a webex meeting to resolve. Are you able to run btrieve maintenance utility in PCC? If so, you have a connection to btrieve, but you might have a macola connectivity problem.

 

[62chev]

Thanks for the assistance. The problem appears resolved. I was looking at the directory structure on our server compared to the documentation from Macola.

Our Structure was:
Company Directory Directory
Number on Server Per Documention *
001 DATA DATA_001
002 DATA_02 DATA_002
010 DATA_10 DATA_010
020 DATA_20 DATA_020

* Documentation states \DATA_XXX contains data files for company XXX

So having tried everything else, I renamed my directories on the server like the documentation says. I received an error message that program has failed.... and login was aborted (now I really broke it!). So I renamed the directories back to the original structure. I was able to login, but again received the DSN error.

It still bugged me that company 01's data directory wasn't DATA_01 but just DATA so I moved the DATA directory to another directory for safe keeping and created a new company 01 (in Macola) - sure enough Macola uses just DATA for company 01's directory. So deleted the new directory the system had set up and moved my original DATA directory back. Shazam the DSN error went away! go figure. My best guess is creating a new company fixed a system file???

The other strange thing I noticed, if I rename the data directory for company 01 to DATA_01 it still works (no DSN error) except when I go into System Manager and bring up the visual menu builder I only see 3 of my 4 companies listed. Company 01 is missing from the list. If I rename the Data directory DATA_03 or 04 or any other number it works fine!

I hope this 'fix' was an exception when it comes to troubleshooting a problem with Macola!

Thanks for the advice regarding support options. I agree with your concerns about using Macola for support. Many times it is a business application question or problem to be solved and software companies typically are not the best at helping.

Thanks again - I can see this forum is going to be a great resource!

Jim

 

[grossow]

I think your problem is with the macdsn.dll. Yours is probably dated 5/29/2002. This is in your macsql/macola7x directory. You need the one dated 1/16/2001.

 

[62chev]

grossow:

You are correct, the macdsn.dll in my macola directory is dated 5/20/2002. Even though things appear to be working now would you still suggest replacing it with the one dated 1/16/2001?

Thanks again for all the help!

Jim

 

[MacolaHelp]

Macola can be picky about wanting the tutorial database installed (Data_00). The ICRs are written for the _data_00_ISOLVE data source. Macola allows for a 3 digit company number, but when you create a new company it creates a 2 digit number unless you specifically put in 3 digits, a holdover from the dos version of the program. The data directory is indeed company 01, but is named data by default in the macola directory tree structure. Working with a macola business partner is usually a better approach than using macola support. If you go the macola support route, you get whoever answers the phone & they don't necessarily understand your implementation. They also don't have much expertise in 3rd party solutions that can really help your installation.

 

[62chev]

Thanks for the explanation regarding the directory structure. I did recreate the tutorial database but Data_00 but don't think it mattered because after deleting it things still work. Would you recommend keeping the tutorial database around - i.e. could we run in to other problems by it not being there?

As far as having a test database we have 2 live companies on the system and a copy of each of these (that we refresh occasionaly) for testing. But if the system expects the tutorial Data_00 database to be there I will put it back.

My best guess is there is a configuration file that PWE was using on the way in that was corrupt and by adding a bogus company the config file was corrected. ????

Just glad it is working.

Thanks again everyone for the help.

Jim

 

[MacolaHelp]

Jim: PWE uses an odbc connection to the database (these limited merant drivers) and loads vba dlls, etc as part of the user interface. I have had problems on & off where updates did not install properly if the users had deleted the data_00 folder. So now, I always leave it there & install it if it has been deleted. Seems to save headaches in the long run. Plus, then you have the latest forms files from macola if you need to rebuild one from scratch. The DSN error usually disappears once you get isolve DSNs set up for all companies & you give registry permissions to all users for macola, pervasive, odbc & sometimes vba.

Are you positive you are pervasive sp4? There are also hot fixes, some of which may affect xp client integration. Did you take spx off the novell server so you are only trying to communicate via tcpip? It will keep your installation much cleaner to delete unnecessary protocols. The odbc connections to pwe's databases are kept in the PCC. Sometimes you have to unload & reload the nwsqlmgr for netware, see infomine 00.662.129. During server startup, the nlms load so fast that some components can be missed. There is an infomine on how to manually reload nwsqlmgr after a server reboot. There is also a reference to a novell patch for xp.

 

[62chev]

Thanks, I will copy the demo database back into our Macola directory. I'm not sure if this explains anything or not but all of the workstations received the DSN error, after I finally got it working on my workstation all the other workstations logged in without error also. (Makes me assume the problem was on the server side).

I downloaded and applied both Pervasive sp4 and the latest hot fix (both the client and the server hot fix). I don't have the details in front of me but I believe I verified based on the version number that it was sp4.

SPX is running on the server but pervasive is setup (through PCC) to only communicate via TCPIP. I need to verify no other applications in the company require SPX then I will disable it on the server.

I will checkout the infomine article on XP and Novell.

I was busted earlier for posting email/contact info. Is there an 'approved' method for contacting others on this forum?

Thanks again for all the help!

Jim

 

[stravis]

Hi Jim,

It is not necessary to remove the SPX protocol from the Novell server. It certainly doesn't hurt anything, but what is important is that the Pervasive data engine is using TCP/IP and TCP/IP alone for network communication. Having the SPX protocol enabled as well as the TCP/IP protocol enabled on either the client or server slows down data connections because Pervasive first tries to connect over SPX and then if that fails it tries to connect over TCP/IP.

As for providing a way to communicate with members of the groups, I don't know of an "approved" way, but I usually will post my email address with some bogus data along with instructions to remove the bogus data and no one has every complained to me. This also keeps you from getting on SPAM lists.

Scott Travis
infoSpring, LLC.

 

[MacolaHelp]

Sorry if I created a misunderstanding on SPX. By removing, I did indeed mean from the PCC server configuration, not necessarily from the server entirely. Pervasive tries TCP/IP first, though, I believe, then spx. Also, make sure that PCC for both client & server have spx disabled for both 32bit & 16 bit. I know macola is supposed to be 32 bit only, but I'd be surprised if all 16 bit components were completely gone. It only takes a few extra seconds to double check the client 16 bit settings. I've seen several people post their emails over time & have responded to some off line myself when a phone call or lengthier discussion has been more helpful than a forum.

 

[62chev]

Thanks for the clarification. I did have a network guru come out today to review our configuration and he suggested if IPX/SPX was not necessary for any of the programs that he would recommend no even loading it at the server level. His contention was it simplifies things, uses fewer system resources and overhead.

He did comment that btrieve may need IPX/SPX to operate on the server level but wasn't sure. He was not familiar with Pervasive 2000i and its requirements (he thought btrieve may require IPX/SPX). To be honest I'm not totally clear on the difference between Pervasive 2000i and btrieve - same thing different name? btrieve replaced by Pervasive 2000i? Pervasive 2000i is the non Microsoft SQL? Any clarification would be appreciated.

 

[dgillz]

Pervasive is the successor to Btrieve....this is not the same as MS SQL.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[MacolaHelp]

Since you are on netware 5x>, tcpip is a native protocol & spx is no longer required for PERVASIVE. However, I am remembering that there are novell functions that autoload btrieve.nlm & it is almost impossible to shut off spx on a novell 5x server. There is a company in Fargo that has worked with novell/macola servers. You need a network person or a macola VAR that understands network & database integration, otherwise you'll spend time with finger pointing instead of problem resolution. Btrieve does not require spx, but can use spx if you have it. MS did not do spx packet handling very well, so tcpip became the pervasive standard since either vendor could handle tcpip.

Pervasive runs both the btrieve transactional nlm (handles API calls from macola to the database) and the pervasive odbc nlm (handles relational queries to the database through odbc sources at the client, or directly at the server if you have admin privileges). That's why you sometimes must reload nwsqlmgr. Everybody's implementation of SQL is a little different, syntax is a little different, but there are many sql vendors out there today. Right now, MS is winning the war to be the only player left on the field after the dust has settled. Next time you need a new server for an ERP app, you will probably be switching to current MS OS & MSSQL. All the major ERP vendors have made it their platform of choice.

 

[62chev]

Thanks for the clarification. If I understand your post correctly Pervasive SQL 2000i is still using btrieve behind the scense so to speak to access the data.

 

[MacolaHelp]

Yes, for macola, the btrieve api calls are made through the transactional engine to the db. For ICRs, they are using odbcs, but there is no updating done from ICRS like there is when you print pick tickets or purchase orders, for example.