Hey guys,
I have been using the forum for information and education purpose for a while now. Recently we got new servers (domain controller and database server) running on Windows Server 2003 enterprise and Windows Server 2003 Standard respectively. We migrated all our SQL goldmine DB files from the old server to the new ones. Since then Goldmine has been working fine, all data gets updated etc. Everything seems to be going well, however since the day we migrated we have been bombarbed with a particualr SQL error that has puzzled us and the Goldmine consultants. The error looks a bit like this:
General SQL error.
Native SQL error: 0
Context: skip 1
MSSQL: GoldMine_GMBase: dbo.CAL
1: Server message:
BDE Error Cat:Code: [51:3]
BDE: 500 [4/11/1999] GoldMine: 6.70.50123
User: AMEET
Window: Gail Cassidy
Template:
Details:
Now, researching on the net it pointed to a network issue but we had a continuous ping on a few workstations to the DB server and it did not fail all day however the error keeps coming on at random times. We have many things but to fail everytime. Has anyone found a solution for this particular error? I would really appreciaate some help.
We are running Goldmine 6.70.50123 CE and all workstations are running Win XP SP2.
The worst part is we are a medical centre and it causes a lot of stress to some staff when goldmine pops with the error and at times pops up the error report closing goldmine completely.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
1. We tried that, all protocols are working perfectly.
2. We are running Windows Server 2003 32 bit Enterprise Edition
3. Implicates CAL, LOOKUP, FIELDS5, MAILBOX etc.
4. What are the pros and cons? Any recommendations with it?
5. Backup/Restore
6. Ok will give that a go.
We have never that particular error before (NATIVE SQL ERROR 0). And it only started after the move.
Some ideas...
Make sure you are using a TCP/IP Alias in the SQL Client Network Utility... Ideally, the alias would be given the Server Name in the top box and the Server's IP Address in the lower box. This will help the workstation know where the server is by IP Address.
I would also reset the user's INI files... there may be some older references to the older server.
Did you run the LInkDocMover from Prior Analytics (http://www.prior-analytic
Are you using an internal DNS Server (do an IPCONFIG /all at a cmd prompt to see where your DNS server is. Ideally , DNS should be an internal (private IP) Address.
What antivirus do you use? Have you tried disabling it to see if the errors go away?
I just had a look aat the TCP/IP alis in the SQL Client Network Utility on my workstation. It was empty, i added in the server name and IP address to TCP/IP protocol.
I reset one of the user's INI file a week ago thinking this might solve it, however that user started to receive errors very soon. The error seems more like a pest.
Yes we are using an internal DNS server which is independent of the goldmine server.
Well,. we had the anti virus running prior to the new goldmine server. Goldmine was functioning fine runing of the old server with the antivirus running in the background.
Again, regarding my #1 point, turning off all the other protocols will force GoldMine to run over TCP/IP. If Named Pipes is turned on, GoldMine will use it if tcp/ip is faulty. If tcp/ip is, for some reason, not working right, GoldMine will automatically use Named Pipes. If Named Pipes is turned off, and tcp/ip is faulty, you'll get an error message -- this is what you want to determine. GoldMine is optimized to use tcp/ip. It will work over Named Pipes, but not properly.
If you discover that tcp/ip isn't working after all, that's what you'll need to fix first; but you really should verify this point.
At 10:30 AM
I am getting one the users to use Goldmine on the server for the day and check if the errors pop up, if they don't then we can somewhat conclude that it could be the workstations. However this is just a hunch.
Progress at 2:15 PM
Ok the result of using Goldmine directly on the server resulted in 0 errors. The users who kopped the most errors were on the server today together terminally. The peformance was much faster, no freezes, crashes (obviously because it was on the goldmine server). However no database errors. Could it be the workstations? Majority of the workstations use MS SQL client, some of them have BDE admin in the common files foder of program files. What could I possibly reset on the workstations and then try goldmine?
You haven't yet demonstrated that tcp/ip is operational as a protocol on your SQL server.
Try this:
1. Open a command prompt on a workstation.
2. Enter this command:
telnet <servername> 1433
hit enter, and see what you get. If the screen turns black instantly, your tcp/ip is operational. If not, then you need to fix that, typically by installing the latest sql service pack.
Domain Controller telnet resulted in connection failed.
Goldmine server telnet worked straight away.
However strangely,telnet was disabled on both the Domain Controller and the Goldmine Server.
Domain Controller telnet resulted in black screen (port 23), it did not work with 1433
Goldmine server telnet worked straight away again to port 1433 but not to port 23
Some computers (usually vista or Win 2008) do not have the telnet program on them.
If you find that you can't use the telnet command to port 1433 on your sql server, that means your sql server is not listening on tcp/ip. You should correct this situation. The easiest, most reliable fix, is to install the most recent service pack for sql. If 1433 tests good from your sql server (i.e. not going through your lan) but not from workstations, this would indicate a firewall problem, i.e. 1433 is blocked from external access on your sql server.
I'm not 100% sure that a Windows update will also automatically update SQL. Your best bet is to open a query window and enter the following query:
select @@Version
Just curious... did you get a chance to try #6 yet?
Another thought... your bde settings are in hklm\software\borland\data
Business Accounts
Answer for Membership
by: stevengraffPosted on 2009-05-07 at 22:42:59ID: 24333290
I don't know what this is, and my guesses may as well be right as wrong... so, in that spirit, here are a few things to look at:
1. Be sure your SQL server is communicating on tcp/ip. To ensure this, turn off all other protocols, especially Named Pipes.
2. You don't mention whether either of your new servers is 64 bit. This could be a problem; this version of GoldMine does not purport to run in a 64-bit environment. (Though it seems that it should, I think.)
3. Does the error message always implicate the CAL table? or does it name a different table from time to time?
4. If you have a good backup you could try doing a full rebuild of the database. Not normally recommended, somewhat extreme, but it could help weed out data issues.
5. How did you move the db? The right way is backup/restore. The less right way is detach/attach.
6. Can you temporarily a) put the db back where it was and see if that helps? and/or b) put the files back and see if that helps?
Is it a coincidence that your error message started popping up after you moved GoldMine? Or is the root cause somewhere in that before/after scenario?