By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,493 Members | 1,233 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,493 IT Pros & Developers. It's quick & easy.

Can a user accidentally create a delete query using the wizard?

P: n/a
Hi,

I have a user that used the Query Wizard to create a query in Access.
Now she claims that her master table is missing all the data that was
excluded from the query. Can you create anything other than a select
query using the Wizard? What do you think happened to her data?

I am working remotely until Friday, so I can't get down to her office
and check out what she did.

What do you think?

Kim

May 31 '06 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Not sure why you have to ask whether or not you can create a delete query
with the wizard. Select a table. Click Insert | Query, and you'll see the
whole list of query types you can create with the wizard.

That said, once the user is in design view of a query, there is nothing to
prevent changing one kind of query to another, including Delete.

Keep in mind that in order to get in this jam, if she did it to herself, she
had to read a prompt that says "You are about to delete xxx rows....Are you
sure you want to do this?" and select Yes.

Good argument for keeping users out of the database window. I have a
routine I call to change some database properties before I release my MDE to
production. How

Call MakePropertyChange("allowbypasskey", False)
Call MakePropertyChange("AllowFullMenus", False)
Call MakePropertyChange("AllowBuiltInToolbars", False)
Call MakePropertyChange("StartUpShowDBWindow", False)
Call MakePropertyChange("StartUpShowStatusBar", True)
Call MakePropertyChange("AllowShortcutMenus", True)
Call MakePropertyChange("AllowToolbarChanges", False)
Call MakePropertyChange("AllowSpecialKeys", False)

That routine is mainly this line:

DB_o_m.Properties(rstrPropertyName) = rvarValue

where DB_o_m is set to currentdb
May 31 '06 #2

P: n/a
What I meant, If a user just went in and followed the prompts by
selecting Query in the database window and then selecting the "Create
Query using the wizard", could they create a delete query, because I
couldn't. (This is the steps she told me she took.)

I hear you about having end users fiddling with the database window; we
didn't want her to even want her to use Access to create the database,
but it comes with Office package, and somebody created it without us
knowing; but as soon as something goes wrong. . . . .
Rick Wannall wrote:
Not sure why you have to ask whether or not you can create a delete query
with the wizard. Select a table. Click Insert | Query, and you'll see the
whole list of query types you can create with the wizard.

That said, once the user is in design view of a query, there is nothing to
prevent changing one kind of query to another, including Delete.

Keep in mind that in order to get in this jam, if she did it to herself, she
had to read a prompt that says "You are about to delete xxx rows....Are you
sure you want to do this?" and select Yes.

Good argument for keeping users out of the database window. I have a
routine I call to change some database properties before I release my MDE to
production. How

Call MakePropertyChange("allowbypasskey", False)
Call MakePropertyChange("AllowFullMenus", False)
Call MakePropertyChange("AllowBuiltInToolbars", False)
Call MakePropertyChange("StartUpShowDBWindow", False)
Call MakePropertyChange("StartUpShowStatusBar", True)
Call MakePropertyChange("AllowShortcutMenus", True)
Call MakePropertyChange("AllowToolbarChanges", False)
Call MakePropertyChange("AllowSpecialKeys", False)

That routine is mainly this line:

DB_o_m.Properties(rstrPropertyName) = rvarValue

where DB_o_m is set to currentdb


Jun 1 '06 #3

P: n/a
I'm sure that by now you've found out that just by following prompts in the
query wizard you cannot create a delete query.

I doubt that that helps you with your situation. As much as you want to, you
can't just walk in and say, "Look, that's not what you did at all. It isn't
possible. You went to the database window, created a select query, changed it
to a delete query, ran it, answered the prompt to delete records, and made a
big mess."

Somewhere in Customer Relations 101 I read that this is not a good opening
gambit.

RW

On 5/31/2006 7:55:20 PM, "forbes" wrote:
What I meant, If a user just went in and followed the prompts by
selecting Query in the database window and then selecting the "Create
Query using the wizard", could they create a delete query, because I
couldn't. (This is the steps she told me she took.)

I hear you about having end users fiddling with the database window; we
didn't want her to even want her to use Access to create the database,
but it comes with Office package, and somebody created it without us
knowing; but as soon as something goes wrong. . . . .
Rick Wannall wrote:
Not sure why you have to ask whether or not you can create a delete query
with the wizard. Select a table. Click Insert | Query, and you'll see the
whole list of query types you can create with the wizard.

That said, once the user is in design view of a query, there is nothing to
prevent changing one kind of query to another, including Delete.

Keep in mind that in order to get in this jam, if she did it to herself, she
had to read a prompt that says "You are about to delete xxx rows....Are you
sure you want to do this?" and select Yes.

Good argument for keeping users out of the database window. I have a
routine I call to change some database properties before I release my MDE to
production. How

Call MakePropertyChange("allowbypasskey", False)
Call MakePropertyChange("AllowFullMenus", False)
Call MakePropertyChange("AllowBuiltInToolbars", False)
Call MakePropertyChange("StartUpShowDBWindow", False)
Call MakePropertyChange("StartUpShowStatusBar", True)
Call MakePropertyChange("AllowShortcutMenus", True)
Call MakePropertyChange("AllowToolbarChanges", False)
Call MakePropertyChange("AllowSpecialKeys", False)

That routine is mainly this line:

DB_o_m.Properties(rstrPropertyName) = rvarValue

where DB_o_m is set to currentdb



--
Science is organized common sense where many a beautiful theory is killed by an ugly fact (Thomas Huxley).
Jun 1 '06 #4

P: n/a
Hi, Kim.
What do you think happened to her data?
Did she save the query? If so, she can open it in SQL View, copy/paste it
into an E-mail and send it to you. If the first keyword is DELETE, then you
know she caused it, not the Wizard. And it still might have been an
accident, because users don't always realize what pushing buttons or
selecting submenu items will do.

I hope there's a backup of the missing data.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"forbes" <> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com... Hi,

I have a user that used the Query Wizard to create a query in Access.
Now she claims that her master table is missing all the data that was
excluded from the query. Can you create anything other than a select
query using the Wizard? What do you think happened to her data?

I am working remotely until Friday, so I can't get down to her office
and check out what she did.

What do you think?

Kim

Jun 1 '06 #5

P: n/a
That's why I keep failing that course.

Of course before accusing somenone of ignoring prompts I would check that
the Tools-Options-Edit/Find-Action Queries option was ticked, because if it
isn't then the user would not get a prompt saying x number of records will
be deleted.

But the rest of your supposed sequence of events I would say seems likely.
--

Terry Kreft
"Rick Wannall" <wa*****@notadomain.net> wrote in message
news:g2******************@newssvr11.news.prodigy.c om...
I'm sure that by now you've found out that just by following prompts in the query wizard you cannot create a delete query.

I doubt that that helps you with your situation. As much as you want to, you can't just walk in and say, "Look, that's not what you did at all. It isn't possible. You went to the database window, created a select query, changed it to a delete query, ran it, answered the prompt to delete records, and made a big mess."

Somewhere in Customer Relations 101 I read that this is not a good opening
gambit.

RW

On 5/31/2006 7:55:20 PM, "forbes" wrote:
What I meant, If a user just went in and followed the prompts by
selecting Query in the database window and then selecting the "Create
Query using the wizard", could they create a delete query, because I
couldn't. (This is the steps she told me she took.)

I hear you about having end users fiddling with the database window; we
didn't want her to even want her to use Access to create the database,
but it comes with Office package, and somebody created it without us
knowing; but as soon as something goes wrong. . . . .
Rick Wannall wrote:
Not sure why you have to ask whether or not you can create a delete query with the wizard. Select a table. Click Insert | Query, and you'll see the whole list of query types you can create with the wizard.

That said, once the user is in design view of a query, there is nothing to prevent changing one kind of query to another, including Delete.

Keep in mind that in order to get in this jam, if she did it to herself, she had to read a prompt that says "You are about to delete xxx rows....Are you sure you want to do this?" and select Yes.

Good argument for keeping users out of the database window. I have a
routine I call to change some database properties before I release my MDE to production. How

Call MakePropertyChange("allowbypasskey", False)
Call MakePropertyChange("AllowFullMenus", False)
Call MakePropertyChange("AllowBuiltInToolbars", False)
Call MakePropertyChange("StartUpShowDBWindow", False)
Call MakePropertyChange("StartUpShowStatusBar", True)
Call MakePropertyChange("AllowShortcutMenus", True)
Call MakePropertyChange("AllowToolbarChanges", False)
Call MakePropertyChange("AllowSpecialKeys", False)

That routine is mainly this line:

DB_o_m.Properties(rstrPropertyName) = rvarValue

where DB_o_m is set to currentdb



--
Science is organized common sense where many a beautiful theory is killed

by an ugly fact (Thomas Huxley).
Jun 1 '06 #6

P: n/a
On Wed, 31 May 2006 20:49:50 -0700, "'69 Camaro"
<Fo**************************@Spameater.orgZERO_SP AM> wrote:

Did she save the query? If so, she can open it in SQL View, copy/paste it
into an E-mail and send it to you. If the first keyword is DELETE, then you
know she caused it, not the Wizard. And it still might have been an
accident, because users don't always realize what pushing buttons or
selecting submenu items will do.

I don't write code, so I'm asking for my education.

Is it possible that she started to type something, decided that she wanted
something else, pushed the delete key, and continued typing. And the first
keyword became DELETE?

Just a wizard prodder
Chuck
--
Jun 1 '06 #7

P: n/a
Good point on Tools | Options, etc.
Jun 1 '06 #8

P: n/a
Hi, Chuck.
Is it possible that she started to type something, decided that she wanted
something else, pushed the delete key, and continued typing. And the
first
keyword became DELETE?
No. Pressing the <DELETE> key just deletes the next character, or the
selected text, or the selected object. To get the word "delete" into a
query, one has to either type the word into the SQL View pane, or use the
Access menu to convert a SELECT query into a DELETE query, or write VBA
code -- or select a macro -- that accomplishes the task. So it's possible
to do it by accident if one is not paying attention before running the query
or the macro. But if the query has been saved, at least one can look at it
afterwards and see whether or not it's a DELETE query, because it's possible
that she, or someone else, has done something else in the database that
resulted in the deletion of data.

Nice try, though. ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"Chuck" <li*****@schoollink.net> wrote in message
news:l7********************************@4ax.com... On Wed, 31 May 2006 20:49:50 -0700, "'69 Camaro"
<Fo**************************@Spameater.orgZERO_SP AM> wrote:

Did she save the query? If so, she can open it in SQL View, copy/paste it
into an E-mail and send it to you. If the first keyword is DELETE, then
you
know she caused it, not the Wizard. And it still might have been an
accident, because users don't always realize what pushing buttons or
selecting submenu items will do.

I don't write code, so I'm asking for my education.

Is it possible that she started to type something, decided that she wanted
something else, pushed the delete key, and continued typing. And the
first
keyword became DELETE?

Just a wizard prodder
Chuck
--

Jun 1 '06 #9

P: n/a
The problem is that the criteria would have to been the REVERSE of the
logic for the query,

Sounds more like she forgot the proper criteria, and got everything in
the query. Then she copied and maybe pasted it into a spreadsheet.

Then, thinking she was in the spreadsheet, she selected all the items
that she did NOT want and deleted them. Only she was in the query and
so deleted them out of the Table instead.

Jun 1 '06 #10

P: n/a
I just remembered an incident from my earliest days with Access. A user
created a select query (probably using wizard, I don't remember), but then
did something disastrous while looking at the data. Finding that she could
select multiple rows, she did so and then used either right-click/delete or
maybe a menu selection. At any rate, what whe had misunderstood was this:
She thought that when she created a query she was making a copy of the data,
like copying a spreadsheet. In her mind, the data she was looking at was
not "in the table", it was "in the query". She was appalled to learn that
when she deleted those rows, she really deleted them, not from a copy but
from the underlying table.

When teaching user classes after that incident I made a point of hammering
this home to users, that the query is not a COPY of the data, it IS the
data. If you delete it, you delete it, for good. It's gone.

Something along this line would support your client's account that she used
a wizard to create the query, but somehow deleted the data.
Jun 1 '06 #11

P: n/a
Rick,
You were the winner! My user did the same thing. She did a query, but
the records were not exactly what she wanted, and then snip, snip snip!

Rick Wannall wrote:
I just remembered an incident from my earliest days with Access. A user
created a select query (probably using wizard, I don't remember), but then
did something disastrous while looking at the data. Finding that she could
select multiple rows, she did so and then used either right-click/delete or
maybe a menu selection. At any rate, what whe had misunderstood was this:
She thought that when she created a query she was making a copy of the data,
like copying a spreadsheet. In her mind, the data she was looking at was
not "in the table", it was "in the query". She was appalled to learn that
when she deleted those rows, she really deleted them, not from a copy but
from the underlying table.

When teaching user classes after that incident I made a point of hammering
this home to users, that the query is not a COPY of the data, it IS the
data. If you delete it, you delete it, for good. It's gone.

Something along this line would support your client's account that she used
a wizard to create the query, but somehow deleted the data.


Jun 1 '06 #12

P: n/a
Ouch!!

I forgot to say that when hammering home this point in the classes I was
teaching, I was typically talking to office workers who had been using
Access for at least several months. I didn't count, but some very large
percentage of them were stunned when I pointed this out, so apparently it's
not an uncommon take on the relation between a query and a table.
Jun 1 '06 #13

P: n/a
Rick,
You were the winner! My user did the same thing. She did a query, but
the records were not exactly what she wanted, and then snip, snip snip!

Rick Wannall wrote:
I just remembered an incident from my earliest days with Access. A user
created a select query (probably using wizard, I don't remember), but then
did something disastrous while looking at the data. Finding that she could
select multiple rows, she did so and then used either right-click/delete or
maybe a menu selection. At any rate, what whe had misunderstood was this:
She thought that when she created a query she was making a copy of the data,
like copying a spreadsheet. In her mind, the data she was looking at was
not "in the table", it was "in the query". She was appalled to learn that
when she deleted those rows, she really deleted them, not from a copy but
from the underlying table.

When teaching user classes after that incident I made a point of hammering
this home to users, that the query is not a COPY of the data, it IS the
data. If you delete it, you delete it, for good. It's gone.

Something along this line would support your client's account that she used
a wizard to create the query, but somehow deleted the data.


Jun 1 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.