My answer to date-passing issues in any situation is usually to put my date in a clearly-defined string format (YYYYMMDD works well), pass the string, and parse it back into a date at the other end.At the moment, you've got implied conversion, and it may or may not be working the same way all the time.

Just make sure it's date, not string, when it gets into your query, or you'll slow the query down (assuming your date field is indexed).

Languages that are not object oriented to begin with should never attempt it.

You know you are describing CF as well, when you say that? It's only had any sense of OO for the last three versions.

As for your code:

* VAR all your variables in your functions;

* I would be very hesitant about having a call to a DB within a loop. Can you not move this process into the DB? Even passing the DB a list of dates would be better than hitting the DB separately for each iteration of the array.

* I would be very hesitant about having a call to a DB within a loop. Can you not move this process into the DB? Even passing the DB a list of dates would be better than hitting the DB separately for each iteration of the array.

-- Adam

I've never been quite sure what effect "VAR"ing has - could you expand?

Agreed about doing your looping at DB level if at all possible.

What's the problem with the code as it stands? What is is doing, or not doing?

I don't know what underlying DB you're using, but it should have some sort of function to convert a string to a date. I'd suggest wrapping that round the parameter in your SQL, to make the conversion explicit rather than implicit. It should improve performance slightly, and you'll be sure that what you're getting is what you intend.

The "var" keyword puts a variable into the highest scope possible; in the case of a function this makes the variable viewable inside the function only.

As an example:

<cffunction name="test"...>

<cfset mynum = 1 />

</cffunction>

<cfoutput>#mynum#</cfoutput>

In the above example, you've set a variable inside a function, but that's now accessible *outside* that function, which is almost always not what you want. If you did <cfset var mynum = 1 /> then the page would error, as mynum would fall out of scope when your function ends.Not var'ing your variables means you can end up with a large number of variables on your page which either you're not aware are there or could end up inadvertendly overwriting a variable of the same name.

In many languages this is the default behaviour, irritatingly in CF it's not.

I don't use Flashbuilder myself, but when I write CFCs for those who do, they prefer me to pass them a query. I don't know their reasons for this, but I assume they have some.

Why pass dates as text, not Date? If you can pass as "date", then yes, that's the best - just as long as you're absolutely sure that both ends mean the same thing by "date". It's the most common thing for any driver to mess up, sometimes in quite subtle ways. But you're not, are you?

VALUE="#ARGUMENTS.dateToSum[i]#">

You have quotes around your date. CF is converting a date to a string, in whatever unspecifed format it thinks is a good idea. Then your database (whatever it is) takes that string, realises it ought to be a date, and converts it back - again, making its own guesses as to what format it's in. If CF and database make slightly different assumptions, you have a problem. If you specify the format in both places, it's back under control.

Each trip to the DB has a reasonably high overhead, getting the call ready, (re-)establishing the connection, making the call, waiting for the DB to get the response organise, sending it back, closing the connection. This is a non-trivial percentage of the entire DB call. So it's best to minimise the number of hits to the DB where possible.

Equally, I usually find when code is looping and then querying within a loop, it's actually splitting the logic between CF & DB because it's convenient for the developer, as opposed to being the best approach, which is usually just to ask the DB to be more work, rather than CF & DB both splitting it. I'm not saying this is intrinsically the case in all situations, but it's definitely always a red flag to (re)assess how things are being done.

I would also hope that Adobe talking to Adobe would use the same definition of "date", but I'm paranoid when it comes to dates, having had problems with them far too often in the past. Adobe talking to MySQL, though.... don't go there!

Repeated calls to the DB from inside a loop should work, its a performance issue, as you say. If what you need is all dates for a month, that's only 30-odd calls, so not a problem.

Just to emphasise Adam's point here, I just knocked up a test page with two methods - the first did 1000 queries to insert one row each, the second looped 1000 times to create one query, then executed it. Results were thus:

One Query: 28 ms 1000 Queries: 713 ms

So yes there's a significant performance increase in only using one query where possible. I appreciate in this case only about 30 rows are being inserted, so let's try that:

One Query: 3 ms 30 Queries: 25 ms

Bear in mind this table only had an id, a number and a string. More complex tables will have even longer execution times.

Sorry for going a little off-subject, just something I've always meant to test properly. Must admit, using fewer database calls is actually even more efficient than I'd expected.

Good points, on this one (a local auto detail shop) convenient for the developer definately gets the nod

Thank you for all the input, its been very helpful.

If I could on one more issue...

I am having all hell trying to pass a simple array of dates into a cfc as an array of dates...

I am processing the datechooser for a list of days left in the month excluding sundays and then trying to pass it up but its a not go.

I have configured input and output to Date[ ] and the cfc as follows,... return type array and input array,... no go.

Curious if you have any quick takes on this... when I try to submit the array as Date[ ] Flashbuilder errors and will not proceed saying i am trying to coerce it to an arrayCollection? Should I just go with it and use the array as the source to the arrayCollection? would that work?

What does Date [ ] mean here as an input and out put array as the notation implies or arrrayCollection?

I wouldn't bother using Date[] - it should imply an array of dates yes, but CF is so loosely typed that if you want convenience just use "array" as the returntype and argumenttype.

As long as you can get Flash to submit to the cfc use the cfmail/cfdump combo from earlier, the cfdump output will tell you exactly what CF is receiving from flash and what datatypes it determines it as.