SQLTeam.com | Weblogs | Forums

SQL Help (With Goldmine) Needed

Hello Everyone,

I use SQL in conjunction with Goldmine. Something happened recently- perhaps a Microsoft update- and this has resulted in me not being able to open Goldmine. When I try to open Goldmine, an error message appears and it reads, " Goldmine Database Connection Problem" The main error reads, "Server does not exist or access denied." It states that the 'Native Code' is 17, and that the 'Source' is Microsoft OLE DB Provider for SQL Server. I can provide a photo of this error message. I am needing to be able to login to Goldmine. I am also wanting SQL to be setup to backup my Goldmine database on a daily basis. I am hoping someone can help me resolve this problem. Thanks in advance!

All My Best,

I recommend SQL Minion Backup


Thanks for the suggestion, Kristen! Is Minion overkill for a 1-person operation?

I don't think so. I think its suited (better than others) where complexity and very detailed control is not required - so for "small shops".

Problem is that some complexity is required ... and I think Minion does a good default "out of the box", so even if you don't know what would be appropriate you'll probably be safe. Once you delve into it you can fiddle, but you might find you don't need to.

SQL (but not SQL Express AFAIK) itself comes with a Wizard which enables building scheduled backups, but Profession DBAs don't have a good word to say about it, and I find its Default Modes scary, so its not a route that I recommend.

We've built our own Backup tool-suite, but that's a big undertaking, and of course if it doesn't work (e.g. in some corner-case) then we'd be stuffed ...

Here's what ours does:

If we create a new database it is added to the "List of databases to be backed up" using the default PLAN. We don't have to do ANYTHING to get a new database backed up.

Default Plan is:

If database name is "RESTORE_*" then don't back it up at all
If database is ReadOnly, Offlne, etc. then skip it
Make a FULL backup on a Sunday (in backup-window)
Make a Differential backup daily (in backup-window)
If Recovery Model is FULL then make a LOG backup every 10 minutes
Optimise indexes and Statistics in backup window
Delete old backup files after retention period (7 days for Logs, and DIFF, 4 weeks for Sunday Fulls)


Log Ship to remote DB
Copy backup files to secondary-location (another server with disk space available, just as belt-and-braces).
(We also have a Cloud Backup which copies any file in the Database Backup folder "regularly")

Backup window = 1AM - 5AM

Separate to that we can "tinker" with the settings on a database-by-database basis, or create a PLAN and apply that to one/many databases. In practice we use the default plan for pretty much everything.

I reckon Minion would do pretty much all of that, without a huge learning curve, but if you use it I'd be interested to hear your "How it went" story and impressions.

My advice is:

Backup to disk local to the SQL Server itself (and THEN copy elsewhere, if that's what you need). Backing up to a network location is more fragile and too many horror stories of that failing, for some reason, and noone getting to know about it.

If you are using FULL Recovery Model then backup the log frequently. 10 minutes maximum I would say, every minute is probably a bit excessive, but if you have multiple people doing data entry and if recreating the data is hard/impossible then every minute is fine.

Ask yourself the question:

If my database was trashed could I recreate the data?

If all your data is generated by people typing in from "Forms" then provided you don't "file" the forms until a database backup has completed you can recreate your data - even if its a pain to do.

If you data is "imported" from some external source you can just "import it again".

But if your data is created by people typing in from reading emails, and taking phone calls, and from generally looking at the data and "amending it", then you can't recreate it at all, and you need near-real-time backups. For that a) only FULL Recovery Model will do and b) you need frequent log backups.