User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:adminmanual:faq [2020/06/11 13:07] joebordes |
en:adminmanual:faq [2022/02/13 09:33] (current) joebordes |
||
|---|---|---|---|
| Line 128: | Line 128: | ||
| !!! Execute this SQL in your database: | !!! Execute this SQL in your database: | ||
| - | <code SQL>update vtiger_users set user_password='$1$ad$hsl2KFybNRnbXBa.b.WWv.', crypt_type='MD5' where id=1;</code> | + | <code SQL>UPDATE vtiger_users SET user_password='$1$ad$hsl2KFybNRnbXBa.b.WWv.', crypt_type='MD5', failed_login_attempts=0 WHERE id=1;</code> |
| ??? How can I deactivate the "Don't show this dialog" or "evitar que este pagina cree dialogo" checkbox on alert messages? | ??? How can I deactivate the "Don't show this dialog" or "evitar que este pagina cree dialogo" checkbox on alert messages? | ||
| Line 169: | Line 169: | ||
| * Recover from a backup of the database. This is the easiest option with the only downside of losing information/work since the last backup, but you are doing frequent backups anyway, right? :-) | * Recover from a backup of the database. This is the easiest option with the only downside of losing information/work since the last backup, but you are doing frequent backups anyway, right? :-) | ||
| - | * If the amount of work done doesn't permit you to recover from the database then you can recover the backup database into a copy, extract the table with the lost data, and copy it into the production database. Now create an update SQL command to update the incorrectly updated fields from the backup table. This option is a surgical backup recovery only of the fields you have updated instead of a full backup recovery. | + | * If the amount of work done doesn't permit you to recover from the database then you can recover the backup database into a copy, extract the table with the lost data, and copy it into the production database. Now create an update SQL command to update the incorrectly updated fields from the backup table. This option is a surgical backup recovery only of the fields you have updated instead of a full backup recovery. [[en:adminmanual:recovermasseditchange|You can read the exact steps here.]] |
| * Another similar alternative to the last step is using the coreBOS history tracker. If you have ModTracker activated on the module you have mass edited, then you have a register of the old and new value in the ModTracker database tables. So you can manually handcraft update SQL commands to recover the original values. This is like recovering from the backup table but harder and you must have ModTracker active before doing the mass edit. | * Another similar alternative to the last step is using the coreBOS history tracker. If you have ModTracker activated on the module you have mass edited, then you have a register of the old and new value in the ModTracker database tables. So you can manually handcraft update SQL commands to recover the original values. This is like recovering from the backup table but harder and you must have ModTracker active before doing the mass edit. | ||
| * If you have Record Versioning active on the module with the mass edit error then it is REALLY simple, you just set the previous version as the active record. I don't remember if that can be done as a mass action but since all the other solutions require going to the database, you can go there also to make the previous version active if it can't be done through the UI. | * If you have Record Versioning active on the module with the mass edit error then it is REALLY simple, you just set the previous version as the active record. I don't remember if that can be done as a mass action but since all the other solutions require going to the database, you can go there also to make the previous version active if it can't be done through the UI. | ||
