Change Query Type To Check Query Before Executing [modified]
-
As an advanced option in my DB GUI I have included the ability to run SQL queries on the DB (an Access MDB). Before running DELETE or UPDATE queries, I'd like to be able to convert them to SELECT queries so that I can issues a message like "This will DELETE/UPDATE 18 records, are you sure?" Does anyone know of any code to do this? I can't believe I'm the only person to want to do it, but Google is failing me. (I know I could probably do this by automating Access, which has 'change query type' functions, but the whole reason for my GUI is that my users might not have Access) Cheers
modified on Wednesday, September 29, 2010 8:55 PM
-
As an advanced option in my DB GUI I have included the ability to run SQL queries on the DB (an Access MDB). Before running DELETE or UPDATE queries, I'd like to be able to convert them to SELECT queries so that I can issues a message like "This will DELETE/UPDATE 18 records, are you sure?" Does anyone know of any code to do this? I can't believe I'm the only person to want to do it, but Google is failing me. (I know I could probably do this by automating Access, which has 'change query type' functions, but the whole reason for my GUI is that my users might not have Access) Cheers
modified on Wednesday, September 29, 2010 8:55 PM
What about wraping the query execution in a transaction, where you would get the number of rows affected, then prompt the user with "Are you sure ?". If the user answers, Yes, then commit the transaction else rollback the transaction. This assumes that you can do transactions in MS-Access .... I'm not sure. Good Luck. :thumbsup:
-
As an advanced option in my DB GUI I have included the ability to run SQL queries on the DB (an Access MDB). Before running DELETE or UPDATE queries, I'd like to be able to convert them to SELECT queries so that I can issues a message like "This will DELETE/UPDATE 18 records, are you sure?" Does anyone know of any code to do this? I can't believe I'm the only person to want to do it, but Google is failing me. (I know I could probably do this by automating Access, which has 'change query type' functions, but the whole reason for my GUI is that my users might not have Access) Cheers
modified on Wednesday, September 29, 2010 8:55 PM
I'm not sure how you handle queries in Access spit but I would replace
DELETEwithSelect Count(*)and execute the select query, use the results to hassle the user and then delete the data. BTW I cannot imagine giving a user the ability to write and execute sql code against the database, advanced or not. The mere fact that you want to get confirmation from your user supports my horror.Never underestimate the power of human stupidity RAH
-
What about wraping the query execution in a transaction, where you would get the number of rows affected, then prompt the user with "Are you sure ?". If the user answers, Yes, then commit the transaction else rollback the transaction. This assumes that you can do transactions in MS-Access .... I'm not sure. Good Luck. :thumbsup:
-
I'm not sure how you handle queries in Access spit but I would replace
DELETEwithSelect Count(*)and execute the select query, use the results to hassle the user and then delete the data. BTW I cannot imagine giving a user the ability to write and execute sql code against the database, advanced or not. The mere fact that you want to get confirmation from your user supports my horror.Never underestimate the power of human stupidity RAH
I know what you mean about user access to SQL - but the support benefits of having this are considerable (not least because it means I don't have to write GUI code for every table blah blah). Still, it'll probably end up hidden behind a secret key combination know only to the enlightened few. Or something like that!
-
I know what you mean about user access to SQL - but the support benefits of having this are considerable (not least because it means I don't have to write GUI code for every table blah blah). Still, it'll probably end up hidden behind a secret key combination know only to the enlightened few. Or something like that!
Do yourself a favor and create a CYA (cover your ass) log table which would capture the SQL statement, User, DateTimeStamp. This will also come in handy when you get the call, "The data was there on Friday !" Also, take frequent backups.
-
Do yourself a favor and create a CYA (cover your ass) log table which would capture the SQL statement, User, DateTimeStamp. This will also come in handy when you get the call, "The data was there on Friday !" Also, take frequent backups.
David Mujica wrote:
a CYA (cover your ass) log table
+5, but wouldn't you rather have a lightweight trace that keeps track of this stuff?
David Mujica wrote:
Also, take frequent backups
:thumbsup: --edit Aw, Microsoft Access, not Sql Server! Forget the trace :)
I are Troll :suss:
modified on Thursday, September 30, 2010 1:03 PM
-
Do yourself a favor and create a CYA (cover your ass) log table which would capture the SQL statement, User, DateTimeStamp. This will also come in handy when you get the call, "The data was there on Friday !" Also, take frequent backups.