SMTPit - resulting in very large file

[Terrible Toll]

I have a batch emailing solution that I built for a client using the SMTPit plug-in from CNS.

It works great and for every email it sends out it stores a record in a sub-table as a log. This sub-table now has 65865 records but the total file size has grown to over 46.8GB!

When I strip out the logfile data, the total file size is a more manageable 580MB.

I don't understand this as the table only contains a few fields with a tiny amount of data in each:

[Timestamp, Status(text), Sender name(text), To name (text), Mail ID(number), Contact ID(number), COUNT records(summary)].

The logfile is built by a script that populates the fields as each email is sent.

Any ideas why this might be happening? Could SMTPit be creating 'invisible' fields for storing attachments or something and why should this be stored with a logfile? or could it be putting invisible data into one or other of the text fields?

All rather perplexing!

Any ideas would be much appreciated - and my thanks to any for consideration of this conundrum.

Anatole

[Terrible Toll]

OK - I have narrowed my search down a bit.

Taking my stupendous 46.8GB file I stripped out fields from the logfile one at a time and hey presto, when I strip out the 'empty' status field the file drops in size by a whopping 32GB. This status field has taken the contents of the "error" field supplied by SMTPit, so I guess there is a bit more to it (like the rest of the email including the attachment maybe?).

Watch this space for the next exciting installment.

Anatole

[VincentO'B]

Hi Anatole

I suppose you have already tried save a copy as... a compacted copy.

[Terrible Toll]

Hi Folks

Got it at last.

The problem was simply that the status field in the logfile was taking accumulating gFullResults from SMTPit for every email in the batch (i.e. status for email 1, then status for email 1 and 2 etc.etc.). This was overloading the file when large batches were sent.

Sorry, I was almost convinced that it might have been some peculiarity with SMTPit, but it was just shoddy programming on my part.

Thanks for the consideration and for 'listening' to a ratty old fool.

Anatole

P.s. Yes, a compacted copy helped, but it wouldn't explain how an essentially perfect sequence of data could stack up so quickly. Cheers Vincent.