Barrie,
The problem has actually been solved (sort of). Here's what happened:
<story>
Since I was copying whole scopes into wddx, the
wddx holds a reference to that scope. For request
scope, the wddx has this near the top:
<struct type='coldfusion.runtime.RequestScope'>
For reasons that I don't understand, when I used
cfwddx to convert the data back to request scope,
it would overwrite the request scope with that
data (only if I was using cfwddx to convert back
request-scope data. So, I changed the
"coldfusion.runtime.RequestScope" part of the
wddx string to something else and that seemed to solve the problem.
As it happens, I realized that I didn't need to
convert that data in that method (only on the
page that shows nothing else but an error dump -
so it didn't matter if request-scope got
polluted. So, I ditched that bit of code. When I
put the code back in (to test for this email, I
couldn't recreate the problem (even though I copied code back from this email.
It is possible that some code on the calling page
changed in the interim as well, but I wasn't
actually referencing that data on the calling page (hence its later deletion).
</story>
Anyway, I am still somewhat curious as to the
problem. As it isn't causing me trouble any more,
however, I won't lose sleep over it.
Incidentally, I agree with you about cfloop. I am
just not as consistent about that as I would like to be.
Thanks everyone for your feedback!
Steve
At 08:50 PM 4/23/2006, Barry Beattie wrote:
Steve:
any chance to see the (relivant) calling code? perhaps a variable is
being used twice or something
also (file under pet-peeve category)
can I suggest a replacement of
<cfoutput query="qErrorVariables">
to
<cfloop query="qErrorVariables">
???
you're not actually outputting anything in that function. I see a lot
of people mis-use cfoutput this way causing the code to be just that
little bit more unclear when it's not necessary.
On 4/24/06, Mark Ireland <[EMAIL PROTECTED]> wrote:
>
> Anything to do with not explicitly declaring Data?
>
> Total guess.
>
>
> >From: Steve Bryant <[EMAIL PROTECTED]>
> >Reply-To: [email protected]
> >To: [email protected]
> >Subject: [CFCDev] Bizarre cfwddx data behavior
> >Date: Fri, 21 Apr 2006 13:02:03 -0500
> >
> >Wondering if anyone has seen this or know of a solution.
> >
> >Running on CFMX 6.1.
> >
> >I am working on a bug-tracking application. It automatically captures
> >errors along with selected data at the time of the error (request scope,
> >for example).
> >
> >In order to capture the data, I use cfwddx to put it into the database.
> >This works fine.
> >
> >When I pull the data out, I use cfwddx again to convert the data back to
> >its original state. This seems to work fine.
> >
> >Except that (at least in the case of "request" scope - haven't tested
> >others) the contents of that scope get overwritten with the data that I
> >pull back into a variable via cfwddx.
> >
> >I am var-ing my variables in the method.
> >
> >Anyone have any ideas on how to prevent this? (code snippet below).
> >
> >If this would be better for another list, just let me know.
> >
> >Thanks,
> >
> >Steve Bryant
> >918-449-9440
> >Bryant Web Consulting LLC
> >http://www.BryantWebConsulting.com/
> >http://steve.coldfusionjournal.com/
> >
> >
> ><cffunction name="getErrorVariables" returntype="query" access="public"
> >output="no" hint="I return all of the ErrorVariables.">
> > <cfargument name="ErrorID" type="string" required="yes">
> >
> > <cfset var qErrorVariables = 0>
> > <cfset var instance = StructNew()>
> >
> > <cfquery name="qErrorVariables"
> >datasource="#variables.datasource#">
> > SELECT VariableID,ErrorID,VariableName,Data
> > FROM bugErrorVariables
> > WHERE ErrorID = <cfqueryparam value="#arguments.ErrorID#"
> >cfsqltype="CF_SQL_INTEGER">
> > </cfquery>
> >
> > <cfoutput query="qErrorVariables">
> > <cfif IsWDDX(Data)>
> > <cfset instance.in =
> >Duplicate(qErrorVariables.Data[CurrentRow])>
> > <cfwddx action="WDDX2CFML" input="#instance.in#"
> >output="instance.out">
> > <cfset QuerySetCell(qErrorVariables, "Data",
> >instance.out, CurrentRow)>
> > </cfif>
> > </cfoutput>
> >
> > <cfreturn qErrorVariables>
> ></cffunction>
> >
> >
> >
> >----------------------------------------------------------
> >You are subscribed to cfcdev. To unsubscribe, send an email to
> >[email protected] with the words 'unsubscribe cfcdev' as the subject of
> >the email.
> >
> >CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> >(www.cfxhosting.com).
> >
> >An archive of the CFCDev list is available at
> >www.mail-archive.com/[email protected]
> >
> >
>
> _________________________________________________________________
> New year, new job there's more than 100,00 jobs at SEEK
>
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau&_t=752315885&_r=Jan05_tagline&_m=EXT
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe,
send an email to [email protected] with the
words 'unsubscribe cfcdev' as the subject of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org)
and supported by CFXHosting (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
>
>
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe,
send an email to [email protected] with the
words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and
supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
