Thank you for fixing the runtime error bug. Now that can be set I have a query on the operation of the POP collector....

If the option is set to not delete immediately messages on the POP server that have been successfully forwarded it appears that each time the POP collector connects to the POP server any messages (whether previously read or not) are forwarded again.

Is this how this should work? I would have assumed once a message was popped from the server successfully it should never be transferred again.

I'm sure there is a way of retrieving only NEW messages from a pop server but I have no idea of teh command syntax you would need to use.

POP Collector should only forward each message once. It keeps a database of UIDs of the messages until they are deleted, and if the database says that it has already been forwarded, then POP Collector won't forward it again.

It should have detailed logs to be able to see what it happening - the UID of the message is shown in the log. The only reasons I can think of for messages to be forwarded each time are either the UID is different each time (which should NOT be the case), or there is something wrong with the database. Do the logs shed any light?

Is this an in-memory database or held somewhere on the disk. Can it be reset or re-created?

I'll monitor the logs in particular the UID's to see if that helps.

It's an Access database (MessageLog.mdb) and can be found in the same folder to which POP Collector is installed. The UIDs are converted to a long hex notation as sometimes the characters sent back by POP servers aren't database friendly (this was found in testing with Easyspace!). If there is an entry in the database for a UID, then the message has been successfully forwarded and shouldn't be again. It also stores the date that it was forwarded so that it knows when to delete it.

How strange...

How you have implemented the collector makes perfect sense however I have searched the entire disk that pop collector is installed on and there is no MessageLog.mdb at all, not even in the install directory.

The program was installed as a service using srvany and seems to work fine (apart from the delete after x hours functionality not appearing to work correctly which generated this thread).

If the MessageLog.mdb database couldn't be generated for some reason would popcollector still work?

That explains everything...

It appears that I left the database out of the installer package. I rebuilt the installer package at some point, and think this is when I forgot to add the database back in - POP Collector doesn't create the database (though I may add this functionality as it is fairly simple to do).

I am rebuilding the package now. I will also upload just the blank database so that you can download it and put it in the POP Collector folder - this should then solve the delayed delete problem.

The updated package and just the database are now available from the POP Collector page.

Please let me know if this solves the problem - though I am sure it will!

If the file MessageLog.mdb is placed in the same directory as popcollector (not in the subdirectory that the zip file contains) it seems to work although I haven't yet seen if messages are deleted from the pop server after the time I set in the pop configration menu for the account being popped.

Does the MessageLog.mdb get bigger and bigger or does popcollector delete entries in teh table once they have been deleted from the pop server?

This utility is getting quite good now I have to say.

POP Collector deletes the database entries when it deletes the messages from the server. In practise the database size does seem to increase over time, but not hugely. I have just checked a system on which it has been running for five years or so, and the database size is 4Mb.

It seems that sometimes entries do get left in the database. POP Collector doesn't currently check if it has entries for messages that don't exist on the server anymore - so if something else deletes the message, the details will remain in the database. While I could add functionality to check, I probably won't as it would involve a fair bit of work for little benefit. If DB size does ever become an issue, you could delete all the old entries manually.

I didn't realise the zip file contained a subdirectory - I will change that! But yes, the database needs to go in the same folder as POP Collector. I probably will add code to create the database if it can't be found - then if I recreate the package again it won't matter if I overlook it!

I couldn't find a subdirectory in the zip file... however:

I have updated POP Collector again. It will now create the database if it doesn't exist. Because of this I have removed the database download - anyone else with the problem simply needs to download the latest version of POP Collector.

One thing I have noticed is that a programmatically created Access database is significantly smaller than one created in Access.

Just downloaded and installed the version 1.0.37. Seems a great improvement, particulaly on initial database size.