Ads were blocked - no problem. But keep in mind that developing HeidiSQL, user support and hosting takes time and money. You may want to send a donation instead.

Protecting tables from accidental deletion/truncate

CelebDAQ's profile image CelebDAQ posted 2 weeks ago in Feature discussion Permalink

I appreciate that there's no mechanism within mysql to do this but I was wondering if this could be built into Heidi?

Yes i know there is a confirm dialog, but it still feels to me like it's too easy to carry out say a Truncate on a table - there should be a seperate setting for each table recorded in Heidi or something that you must remove to allow you to execute such a command.

ansgar's profile image ansgar posted 2 weeks ago Permalink

Don't you think that would make deleting really cumbersome if you are sure about what you're doing?

Also, I don't get what you mean with a seperate setting for each table - where and how would the user unset that setting, or flag?

CelebDAQ's profile image CelebDAQ posted 2 weeks ago Permalink

Hi

I was thinking about a right click, properties, checkbox type thing. It could save the settings in a config file or a "Heidi-settings" table in the db (which is read at db open. Yes it might be a feature that some dont use but others might like the extra saftey net.

Ads were blocked - no problem. But keep in mind that developing HeidiSQL, user support and hosting takes time and money. You may want to send a donation instead.
BubikolRamios's profile image BubikolRamios posted 2 weeks ago Permalink

In general same or even more catastrophic thing can be done with maria db extended REGEX. You do the s..t and you even don't know you done it. No check for that can be set anywhere.

I do see your point but then 'extra saftey net' would pile up.

Maybe there is a Mysql privilege settins per user in mysql, didn't check that...

CelebDAQ's profile image CelebDAQ posted 2 weeks ago Permalink

Of course there isn't anyway to protect against you having a "moment" and running a command the ends everything. That would be down to mysql to protect against which we know it doesn't and so the only real solution is to use multiple user accounts with different access permissions - which is a pain but thats a whole other subject.

I'm more thinking about combating the accidental UI clicking where it's far easier to destroy a table/db with very little thought. At least with commands you have to actually get typing a whole host of stuff so it's a bit more involved.

ansgar's profile image ansgar posted 1 week ago Permalink

I get the point now. I'm just still thinking the current prompt after clicking "drop" is enough user involvement:

Description

Even the cancel button is the active one by default, so when you just press Enter without thinking, nothing happens.

Another way is to refine your account privileges with some granularity, e.g. remove DROP privileges. This can also be done on a database and table level. Very safe, even against accidental custom query execution.

Description

CelebDAQ's profile image CelebDAQ posted 1 week ago Permalink

Aye thats seems like a solution but it's a bit global. My thinking is that there may be some tables where you want to ensure that you don't accidentally or in a fit of madness drop them but others it will be fine. The problem I have is that my hosting company won't allow me to alter the user permissions - Heidi is giving me an error (1227) saying I need RELOAD permissions.

If thats actually a Heidi issue then whats the fix but if its the hosting company then they probably won't budge on it which means altering user permissions isn't an option for me (haven't discussed that with them yet though).

Please login to leave a reply, or register at first.