What you are dealing with is what's known as concurrency issues... and it's something that is at the heart of every centralized database system. There are a couple of ways of dealing with it. Actually, let me back up some. Your question isn't entirely clear on what kind of queries we're talkng about... a selection query or an action query ... selection queries are just that, queries that select data. Action queries actually perform an action, Insert, Update, Delete. With Select queries, concurrency is generally a non-issue. That leaves Inserts, Updates and Deletes.
Insert - It is very rare for two users to be entering the same new record at the same time. I can't even think of a fringe case where that would happen - actually, in the case of one of my clients, I could see it happening, but even for them it would still be a stretch.
Delete - if two users try to delete the same record at the same time ... one is going to get it and the other isn't. I'm not sure how much of an issue that is, but you can test for the record, and if it's already been deleted, simply report back to the user that it's been deleted (optionally tell them that someone else did it.)
That leaves updates, where the biggest issue of concurrency happens. Generally, there's two ways to deal with this: optimistically, and pessimistically. In the optimistic mode, you simply update the record. You're "optimistic" that your data is the latest and greatest. It's also known as "last one to update wins." In a previous life, this is how we dealt with it. We let our customers know, and for the most part they were OK with that and understood the ramifications. Due to the nature of their business, it was highly unlikely that there would be concurrency issues in the first place.
In the pessimistic mode, it's more of a "trust by verify" kind of mentality... you're trusting that you have the latest, but you verify it first. This is usually done by putting some kind of timestamp on the record. When you read the record, you grab the timestamp. When you then go to save, you first check the stamp on the record, if it has NOT changed, you issue the update... if it HAS changed, or is different from what was loaded, it means someone updated the record since the user last loaded it. You can then notify them, throw an error, or something to indicate to the user that something has since changed. This is what the system I work on now does. Every record in every table has a TS field that gets loaded when the record is loaded. On a save, the loaded TS is compared to the database TS and if they differ, an error is thrown and the user is notified that the record has since changed and cannot be saved.

There are other ways as well, such as merging, and if the data is simple that's fairly easily done... but if the data is complex in any way... it can become a big mess real quick.

-tg