The next problem this created for me was in the way I normally had been grabbing the newly created records in my Access tables. I guess it’s pretty standard for most people to do something along these lines when creating and inserting values into your access tables:

1
2
3
4
5
6
7
8
9
10

<cfquery name="test1" datasource="source1">
     INSERT INTO Table (datacol)
     VALUES ("datapiece");
</cfquery>
 
<cfquery name="getID" datasource="source1">
    SELECT MAX(ID) as MaxID FROM Table
</cfquery>
 
<cfset myID = getID.MaxID />

Well this didn’t work anymore with the Random seed for the AutoNumber. The max was no longer the last one inserted. It led to quite a bit of hair pulling on my part – and that’s an accomplishment when you’re bald. So I had heard from a co-worker that @@Identity did in fact work in Access. I hadn’t spent much time looking into it – being as I had a solution that worked (Max(id)) and I prefer to work in SQL Server or MySQL. But now I was presented with a need to figure it out. A few minutes of Googling led me to this article by Charlie Arehart from 2002(!) I was a little surprised to see it had been working for this long. So now I do my access inserts like this:

1
2
3
4
5
6
7
8
9
10
11
12

<cftransaction>
      <cfquery name="test1" datasource="source1">
             INSERT INTO Table (datacol)
             VALUES ("datapiece");
      </cfquery>
 
      <cfquery name="getID" datasource="source1">
             SELECT @@IDENTITY as MaxID;
      </cfquery>	
 
      <cfset myID = getID.MaxID />
</cftransaction>

And everything works out just fine. The keys are the CFTransaction tag and using two separate CFQuery tags. Now to go revamp a whole section of code to use this little tidbit!

The root cause was that: java.sql.SQLException: Datasource names for all the database tags within CFTRANSACTION must be the same.

This seems pretty straightforward, until you start digging into the problem, and become led down a few wrongs paths courtesy of google serving up results that aren’t entirely true.
One of the discussions I found was an adobe tech note, which I discovered via a link from a post by Ben Nadal.  In this tech note, the solution was to simply replace all cfexit tags, with a cfabort.

Simple, yes, except that I had NO cfexit tags within my cftry/cftransaction statement, they were already cfaborts!

Further investigation revealed that you simply cannot have multiple datasource names withing a cftransaction.

Now, with no actual documentation on the subject, and not actually knowing what spell coldfusion is uttering while it waves its wand over its magic hat, I cannot give a ‘good’ reason as to why.  All I know is the problem was fixed once I removed the offending query to outside the cftransaction.

In order to duplicate the desired effect, you will have to keep track of the transactions, and rollback/commit based on the prior cftransaction attempts, which is a discussion for another post.

-Dave

What I’m referring to is, of course, coldFusion deciding that it only wants to do things a certain way, regardless of how you *think* the process should go.

Not too long in the distant past, I encountered such a beast, and will relate my story now.

The task was simple:  connect to a webservice, and display the results.  As the project progressed, the rules changed slightly – now I needed to grab the results, and filter out any that didn’t belong based upon a criterion set.  Never you mind that usually, the web service would be changed or manipulated so that a parameter or two could be passed in & perform the filtering on the server side.  That wasn’t a possibility in this case, and wouldn’t prove to have been near as much fun.

The rumblings and mutterings from the nether world began when I attempted to loop over the results and filter out any which didn’t fall within the specified criteria.  Normally, this would just involve a cfif tag to test each set of returned data to decide to display it or not.  The crux of the problem was that before entering the loop, the count of how many records were returned was displayed.  Depending on how many records were excluded, this count could be, and was, way off of the actual records that were displayed.

My initial theory was to loop over the record set returned from the webservice, and use a structDeleteAt() call to remove any records which did not match what I was trying to display.

*KABOOM*

ColdFusion refused to delete the record.  I tried everything.  Setting the value to empty, using a Javacast to set it to null, even copying the returned result set, and working with the copy.

None of it worked.

ColdFusion liked how the returned result tasted, and wasn’t about to let go, not for any amount of cajoling or cursing at it.

Finally, defeated, I tried a different approach.  Instead of using any trickery, or established CF functions or methods, I decided to bring a howitzer to this knife fight.

The answer lies in the code below.

<cfloop from="#ArrayLen(serviceReturn.contacts.anyType)#" to="1" step="-1" index="i">
<cfset tmp = serviceReturn.contacts.anyType[i] />
<cfset tmpPaidThrough = tmp.getPaidThrough() />
<cfif EXPRESSION_TO_CHECK_AGAINST >
<cfset tmpInsert = arrayappend(session.searchResults,serviceReturn.contacts.anyType[i]) />
</cfif>
</cfloop>

To explain:

• loop over the record set returned by the webservice.
• set the record to a temp variable, and get the part that we want to check against (in this case, paidThrough)
• if the record passes the test, append it to a new variable (session.searchResults)
• note that I have gone from the end of the struct to the beginning, but I believe it would work either way

Then, in the display portion of the code, instead of using the returned record set, we use the new variable we set up that only has the records in it that have passed the test for display purposes.

*VOILA*

ColdFusion, realizing that it has been defeated, slinks off to haunt some other poor soul.

I’m not entirely sure why CF would not relinquish the record of the returned set.  In discussion with other developers, we reasoned that perhaps since the return was a struct of struct of structs, somewhere in the vast underlying java mysteries, the pointers could not be moved or deleted, so CF did not want to delete the data.  Copying the returned structure resulted in a structure of the same design, so CF wasn’t able to delete from a copy any more than it could from the original record set.

So there you have it.  Wipe the blood off your sword, hoist a beer, and move on to another realm, full of it’s share of demons and battles.

-Dave

CFSilence:
CFGoogle

RiaForge:
http://cfgoogle.riaforge.org/

1
2
3

      <entry key="devFilepath">
               <value>${baseFilepath}\logs</value>
      </entry>

Won’t work. The ColdSpring engine won’t find this as a configuration to populate. Instead, you have to make sure the whole space between the tags is what you want to have replaced, like so:

1
2
3

      <entry key="devFilepath">
               <value>${devFilepath}</value>
      </entry>

Hope that helps someone out!

The second time I ran into this – just a few moments ago – was the same problem surfacing because the declaration for the form had been placed inside the declaration for the table.

1
2
3

<table>
         <form></form>
</table>

This just did not sit well with the browser, being invalid and all.  Once I moved them outside of that formation and made it this:

1
2
3

<form>
      <table></table>
</form>

it worked like a champ.    Hopefully this helps someone out there with this error in the future!

http://snurl.com/j7e56