Josh R wrote:
>
> PLEASE READ CAREFULLY
>
> (Technical info - Using CF 4.5.2 to query MS Access 97 SR2 database for a
> text field and date field for unknown number of recordnumbers)
>
> OK. I have flushed the query by making a dynamically changing query name
> (I.E. cfquery name="shipments#uniquefield#") and made the page reload using
> both unique html calls (I.E. updatecart.cfm?ID=#uniquefield2#") and
> (meta http-equiv="pragma" content="no-cache")
> (META HTTP-EQUIV="Expires" CONTENT="Mon, 06 Jan 1990 00:00:01 GMT")
> codes.
>
> It even loads itself into a second page with the exact same code with all
> NEW uniquefields. There is no way (that I see) this query can get "old"
> data.
>
> BUT, that's exactly what it's doing. It grabs the data previous to updating
> the database (even though the database has been verifyably updated before
> this query.)
>
> I've even rewritten the query to see if it was just how the query was
> written. It still occasionally grabs "old" data.
>
> In short, grabbing this particular information sometimes grabs "old" data
> instead of what is verifyably in the database.
>
> This problem does not occur on ANY other queries throughout the entire site.
>
> Original Query
>
> (cfquery name="shipments#uniquefield#" datasource="mine" dbtype="ODBC")
> SELECT shipdate, shipmethod, Count(*) as totalCount
> FROM shopcart
> WHERE MyCart = '#url.cart#'
> Group by shipdate, shipmethod(/cfquery)
>
> Different Query asking for same
>
> (cfquery name="shipments#uniquefield#" datasource="mine" dbtype="ODBC")
> SELECT shipdate, shipmethod
> FROM shopcart
> WHERE MyCart = '#url.cart#'
> (/cfquery)
>
> Both Queries often come out with "old" data.
>
> Why is this data stuck? Why is this only happening with this info? Why am I
> being tortured like this?
Well, it's basically the same query though.
Try using the cachedwithin attribute.
<cfquery name="shipments" datasource="mine"
cachedwithin="#CreateTimeSpan(0,0,0,1)#">
I'm not sure why its cached now (could be a setting in the administrator
or in Access) but this will set the cache to 1 second, which has always
refreshed the cache for me. I don't know how this would handle if Access
is caching it somehow. I hardly ever use access and I haven't had this
problem.
HOWEVER, I see some other issues with what you're doing.
The first thing is storing the shopping cart in the database. I'm hoping
that this shopcart table stores the data that's been confirmed and
ordered and the customer expects to be charged. If not, you're going to
have some problems. One main problem is clearing out cart data for items
that haven't really been ordered, assuming that you are detecting
somehow whether or not they were really ordered. If you aren't detecting
that, you're going to end up with lots of useless data that will bog
down your system and depending on exactly what you're doing, you could
charge people for things they didn't order.
These are some of the reasons that shopping carts are ordinarily stored
in session variables until they are submitted to the database. They
usually go into an orders table so I'm assuming that this isn't what
you're doing.
But here's the biggest issue that I see. You're passing the identifier
for the cart in the URL. I hope I hope I hope you are using a unique id
for this but even if you are, this is scary. You know all those reports
you hear on the news about some website that was set up so that if you
did some small thing you could see other customers' data? This is what
they are talking about. If you pass this kind of info through the url,
all it takes is changing the value of one variable in the URL and you
could get someone else's data. And dear Lord you will get reamed for
that. Your immediate response will probably be "Form variables!" Just as
bad. Well, not just as bad. It doesn't take much to find out what to do
to get things out of your data but it doesn't scream "Hack me!" like a
url variable does.
I know that the temptation is to pass indentifying info in the url or a
form variable so people can order without cookies. However, it's a bad
idea. It has major security issues and when you're talking about an
ordering system, you're talking about credit card numbers. You need to
do whatever you can to protect those credit card numbers.
You probably have a boss that's saying to you "Everyone needs to be able
to order! People with Netscape 3 need to be able to order! People with
no cookies need to be able to order! Everyone! We need everyone to be
able to order! Turn no one away!" While I understand the intention, the
effect is a shopping system that is EXTREMELY hard, if not impossible,
to secure. If you do have a boss that is really insistant about that,
tell him that the system will not be able to stop people from stealing
credit cards. If the boss still insists, you need to consider who will
be blamed if credit cards do get compromised. Even if you warn
him/her/it, you'll probably be the one blamed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
