>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?
>Jennifer Larkin Responded with:
>
>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've already tried that. I even went so far as to go
cachedwithin="#CreateTimeSpan(0,0,0,0)#". It doesn't help. Believe me. I've
become quite the expert regarding de-caching. Well, obviously that isn't
true, otherwise I wouldn't have this problem, now would I? :-}
The fact that it's "basically the same query" doesn't stop the rest of the
calculations from updating properly. It's only this particular query that's
being affected. That's the annoying part.
>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.
While I appreciate your concern over the layout of the site, all the issues
you bring up are non-existent (to the best of my knowledge). That URL
variable has no bearing whatsoever on access to credit cards or any other
damaging information. It's only passed through 4 pages, which most people
won't notice. The calculations for the variable is difficult to duplicate
without the formula in the first place, and not any easier even with my
formula so it'll be hard for someone to "guess" a correct variable that
hasn't been "closed out". (If someone does try tampering, I have blocks and
alerts placed in various locations) The database bloat is a non-issue since
we have a "flush" script dumping open data that's too old. The only thing
available is locked out invoices and customer info that only the customer
has access to. The database itself is not accesible through http browsing.
They'd have to hack into the system itself, and that's a whole 'nother ball
o' wax.
I'm not saying I'm hack-proof. I'm just saying that I don't think our site
has any "obvious" holes.
Now, can we get back to my original problem. How do I fix this gosh-darned
query caching?
Is it possible that searching a text field and time/date field together is
the problem? I know it makes no sense, but I'm at my wit's end, and I'm
reaching now.
Help!!
Josh
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
