What "things" get asynchronous? If what you say is true, email would
regularly go out without complete attachments. I think you're way off
on this one.
-dhs
--
Dean H. Saxe
[EMAIL PROTECTED]
On Nov 8, 2008, at 5:20 PM, "Douglas Knudsen"
<[EMAIL PROTECTED]> wrote:
caching would be at the webserver level with respect to this. My
guess is the email gets sent prior to the new PDF being completed.
Emails are queued and file saves involve file system work-time, so
things get a bit asynchronous. Even with unique file naming schems,
this can be a issue. Try the unique naming approach, the possible
error would involve the email engine not being able to find the file
when the email is to be sent. If this doesn't work reliably, I'd
look at inline attachments. This latter approach would put the PDF
in the email itself as a attachment wiht the added bonus of not
needing to be placed in the webroot.
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
On Sat, Nov 8, 2008 at 10:45 AM, Peyton Todd <[EMAIL PROTECTED]
> wrote:
It's just that caching is the only explanation I can think of, and
if that's the reason, then deleting the earlier version of the file
would do no good if the cached version is what's being sent. On the
other hand, I have not verified that indeed the second version is
indeed being created, so more research is necessary...
-----Original Message-----
From: "Dean H. Saxe"
Sent: Nov 8, 2008 10:09 AM
To: "discussion@acfug.org"
Subject: Re: [ACFUG Discuss] Another CFMAIL Problem
I still don't get what it is you think is caching the file. Why not
just delete the PDF as soon as you have emailed it?
-dhs
--
Dean H. Saxe
[EMAIL PROTECTED]
On Nov 8, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote:
Sounds like my original response. Check for the file first...
Sent via BlackBerry by AT&T
From: "Howard Fore" <[EMAIL PROTECTED]>
Date: Sat, 8 Nov 2008 09:19:22 -0500
To: <discussion@acfug.org>
Subject: Re: [ACFUG Discuss] Another CFMAIL Problem
Why not go ahead and use the job number, but when you're about to
write the PDF to disk first check to see if there's already one
with that name (initials and job number). If you find one then
delete it, then create the new one. Is there some audit reason to
keep the earlier version?
On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd <[EMAIL PROTECTED]
> wrote:
One solution I thought of is simply to use the job number as the
name of the PDF. This would guarantee that each next one built is
different. But then it occurred to me that if the user reports a
job, then realizes he made a mistake, corrects it, and sends the
report again for the same job, there's a danger that the earlier
mistaken version would get sent instead.
--
Howard Fore, [EMAIL PROTECTED]
"The universe tends toward maximum irony. Don't push it." - Jeff
Atwood
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?falogin.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
