We run SpamFilter (latest build 206, registered version), quarantining to a Microsoft SQL 7 database server.  MDAC 2.7 SP1.  We run the app, not the service.  Our connect string is saved in a .udl file, as per SpamFilter guidelines.

Every time that we shutdown SpamFilter for any reason -- server reboot, shutdown to install the latest executable, etc. -- we must manually reconnect to the database after we start SpamFilter.  Sure, it's easy to do (just 3 clicks)... click Quarantine DB, click the "Step 3" tab, then click the "Save & Activate Conn String" button.  Still, it's just another thing that we have to remember to do after starting the application.  The other day, I forgot, and until I discovered my mistake a half-hour later, messages were being rejected but not quarantined.

My question is this: is there a way to set SpamFilter up to connect automatically to the database, using the connect string saved in the .udl file... as soon as the application is started, WITHOUT having to click -- click -- click to reactivate the connection to the database?

If there's already a way to do this, and I've somehow missed it, let me know... but if there's not currently a way to do this, could a "connect automatically on program launch" option be added in a near-future release?

Thanks

Jim,

Check your INI file for the setting tblServersServerID=x where x is some number.  Then in the database, check the "tblServers" and make sure that the entry for your server matches.  I run several instances of SpamFilter and ran into the same issue when those setting go out of whack.  I have since changed the permissions on that table (not recomended) so that an install of SpamFilter can not alter the table and I add an entry for each running instance manually setting a unique name for eace "virtual" server and then make the tblServersServerID=x setting agree.

I do not know if this is the same issue but get let me know.

Regards,

Dan S.I

Dan,

Thanks for the info... but everything appears to be OK here.  tblServersServerID=1, and there is a single record in tblServers that matches (ServerID = 1, ServerName = 'SF1').  We run only this single SpamFilter server.

Jim

Jim,

SpamFilter automatically connects to the database server when it starts up, either in service mode or as a standalone app. Should the database server become unavailable while SpamFilter is running, incoming emails will still be processed. Spam will be still rejected, but will not be quarantined until the databse is back online. No user inervention is needed, when the DB is online again SpamFilter will automatically see it and resume quarantining.

When you start SpamFilter, can you please go to the "Quarantine" tab and check if the quarantine DB status says "The Quarantine DB is active" or not?

Roberto F.
LogSat Software

Roberto,

I just now took the following steps.

1. Shut down the SpamFilter app., and waited approximately 15 seconds.
2. Restarted the SpamFilter app.
3. Navigated to the Settings - Quarantine DB page.  The text on the right side of this page reads "The Quarantine DB is not active" and the other controls in this window (number of days, quarantine interval) are disabled (grayed out).
4. Clicked on the "Step 3" tab on the left side of the screen.
5. Clicked the "Save & Activate Conn String" button.
6. The text on the right side of the page immediately changes to "The Quarantine DB is active" and the controls are enabled.

Thanks,

Jim

Jim,

Can you please, when SpamFilter starts, go thru the 3 steps in the "Quarantine DB" wizard? When you get to step 2, click on the "Create/Check Database tables" button, and copy&paste the results of that test to us here in the forum. If there's a problem with the database schema it will be reported there.

After that is done, can you please verify that in the SpamFilter database, the following tables do have the required fields:

•   tblLogins : 'LoginID; EMail; Password';
•   tblMsgs :  'MsgID; Msg';
•   tblQuarantine : 'QuarID; EmailFrom; EmailTo; Subject; MsgDate; MsgID; RejectID; RejectDetails; Deliver; Expire; ServerID';
•   tblRejectCodes : 'RejectID; RejectDesc';
•   tblServers : 'ServerID; ServerName';
  

The only way we could reproduce this behavior was with a table that was missing one of these fields, and not going thru the wizard to fix them.

Roberto F.
LogSat Software

Roberto,

Actually, there was not a problem with the table schema, but somehow SELECT permission did not get set on tblServers.  The "Step 2" screen did indeed detect this problem.  Once I corrected the permissions on the table, everything works great.

Thanks,

Jim

The tblServers permissions is the original issue I was trying to point you to with my first post.  I am very sorry I was not more specific with my statement about manually setting the permissions.

Dan S.