Hi,
As per your quote,
then wouldn't it be possible that cfmail could grab the old value from the
SQL Server column (presumably via its 'query=' parameter?) before my SQL
Server update statement stuffs the new value into it?
Well, once you store something, lets say beforeupdate_identColumn.pdf , now
you have a file mapping to identity column. So lets say user changes or
modifies something, then you do update *first* based of identity column.
Then you either create that pdf or send it as an attachment. Makes sense? My
feeling is that once you have anything in DB, you are the master of things.
You can do pretty much anything like update, track changes, come back at
later time and still create docs which might be from way back in time and
what not. Bottom line, you are in control.
Here is simple logic :
step 1. create pdf content variable . I guess you could do this,
<cfsavecontent variable="pdfcontent"><table>blah blah
</table></cfsavecontent>
step 2. insert into db. insert into pdf_table(pdf_content) values
('#pdfcontent#') ( what i mean here is to save pdf text with table
formattting etc in the column.
step 3. Now whenever your ready you could
a. lets say user updates pdfcontent, then you do udpate query first, so you
have latest content.
step 4. get the latest content from the table and
a. create pdf using <cfdocument> #pdfcontent#</cfdocument> or
b. send it as an attachment.
this way you will know for sure, if it was right content or not. Right now
seems to me, its more of guess work and there is no way to make sure you are
sending the so called cache vs updated content.
hope that helps.
Ajas Mohammed.
On Mon, Nov 10, 2008 at 12:23 AM, Dawn Hoagland <[EMAIL PROTECTED]>wrote:
> IF you can send a link to the server AND he always needs the latest version
> (and assuming it doesn't take long to generate the PDF) - I would send a
> link to a page that generates it on the fly every time and allow him to
> download that version when needed - as previously mentioned by Howard. This
> eliminates any issues to do with email latency (or the possibility of
> caching) and gives the opportunity to close some security holes created by
> leaving content in an unsecured location.
>
> Dawn
>
>
> On Sun, Nov 9, 2008 at 8:26 PM, Peyton Todd <[EMAIL PROTECTED]>wrote:
>
>> Doug, your guess that the email gets sent before the new PDF gets built
>> rings true to me. It would explain the problem on my client's server, as
>> well as the fact that it's not happening to me right now testing the system
>> working on my own PC as localhost. It jogs my memory that my coworker
>> experienced a similar problem back about 2001, when I was programming
>> ColdFusion in New York City. (?New York City!?? Get a rope!)
>>
>> Dean, doesn't it make sense to you that the e-mail could get sent before
>> the second version of the file gets built, so it merely picks up what it
>> finds on the disk , namely, the earlier version of the file? Actually, come
>> to think of it, that would not be an instance of caching.
>>
>> Ajas, I don't know, but it seems to me that saving the PDF into a SQL
>> Server column might have the same problem as that described by Doug: if
>> these operations can be performed asynchronously, then wouldn't it be
>> possible that cfmail could grab the old value from the SQL Server column
>> (presumably via its 'query=' parameter?) before my SQL Server update
>> statement stuffs the new value into it?
>>
>> Howard, No, I didn't mean the office manager might get mixed up on which
>> file is which - he's reasonably computer literate, and knows perfectly well
>> that the one on top was sent later (Whoops! It just occurred to me that that
>> might not always be true if there's a glitch in the e-mail process...).
>> Anyway, though, what I did mean is that it's simply the older version of the
>> file that gets attached to the e-mail. Your idea of sending a link seems
>> like a good one, and I may try that but ...
>>
>> >>> Naming the PDF by the Job Number instead of by the reporter's ID is
>> necessary of regardless of whether I attach the file or send a link. In
>> either case, I'd be writing the file to disk. If I were to delete any old
>> copy beforehand, what are the chances that (if this asynchrous story is
>> true) cfmail would fail to find the file when it looks for it and throw an
>> error?
>>
>> Peyton
>>
>> -----Original Message-----
>> From: Howard Fore
>> Sent: Nov 8, 2008 8:12 PM
>> To: discussion@acfug.org
>> Subject: Re: [ACFUG Discuss] Another CFMAIL Problem
>>
>> I think what he means is that if a recorder creates a file and sends it,
>> then corrects it and sends again, the recipient could open the first one and
>> think it is the most current version when it isn't. It wasn't identified as
>> an issue by Peyton but I could see how it could cause someone an issue. My
>> response to that would be to not mail the PDF as an attachment but rather
>> email a link to the user. The link would either lead to a real PDF, stored
>> on disk, or to a CFM file that generates the PDF when it is requested. That
>> would get rid of any caching issue as the file requested is always the
>> latest version.
>> On Sat, Nov 8, 2008 at 6:19 PM, Dean H. Saxe <[EMAIL PROTECTED]
>> > wrote:
>>
>>> 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.
>>>
>> --
>> 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 <http://www.fusionlink.com>
>> -------------------------------------------------------------
>>
>> -------------------------------------------------------------
>> 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 <http://www.fusionlink.com>
> -------------------------------------------------------------
>
--
<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.
-------------------------------------------------------------
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 http://www.fusionlink.com
-------------------------------------------------------------
