I am the superuser of a particular database schema. Therefore I have all privileges on the tables in this schema, including ALTER DELETE UPDATE and INSERT.
I am administrating this database using the GUI MySQL Workbench 6.3. I used to select rows and to obtain a read-only result grid, which was convenient because it prevented me from accidentally editing data in my table.
This was indicated by a 'read only' flag in the bottom right corner of the result grid (see below).
However, I did not change anything in the structure of the table, and now when I select rows I am able to edit data and the 'read only' flag has disappeared.
I find it a bit unsecure because it would mean I could accidentally edit data in the table by mistyping.
How could I revert to a read-only result display?
The rules that allow editing a result set are very strict. The select query must be a plain one - no aggregate functions, no joins, no unions. There must be a primary key which is used to address the records to be changed.
Update: it wasn't necessary to worry about accidentally editing records in the table while not being in read-only mode.
Indeed, if you change a record in the table (in the screenshot below, I changed a year from 2010 to 2020), for this change to be actually committed in the database, you would need to click the "apply" button in the bottom right corner.
Moreover, upon closing the tab, you are asked whether or not you want to save changes. Consequently, if you accidentally edited a record, you just have to click "Don't save" upon closing the tab.
Related
I have spent two days researching and try to fix my issue with access form edits. I understand that there may be similar questions out there, but none of the suggestions fixed my problem. Also, my situation might be slightly different.
I'm on Access 2017 and using an access split form that is tied to a linked table that is on sql server 2017. I have an add button that simply adds the record entered and moves to a new record. When I add a record to my form and then try to edit it in the datasheet view on my split form I get a write conflict error.
I've already validated that I have a primary key on my table and that there are no null bit fields.
The other thing to note is that this started happening after migrating from SQL server 2014 to sql server 2017.
One thing I read about and have yet to try because of the "drastic" change it entails is to set the compatibility level of my database to something lower like SQL 2014. This would be a last resort however and would only be to validate what the cause of the error might be.
I've tried everything on this page that is applicable to my situation: http://www.accessrepairnrecovery.com/blog/fix-ms-access-write-conflict-error
What else can I try to resolve this? I'm hoping someone out there has run into something similar.
First this question has been answered 100's of time on stack overflow.
Next up: Your link has nothing to do with using SQL server, so the suggests likely will not help.
The main causes (repeated over and over as solution) when using Access and SQL server are:
Ensure that all tables have a PK defined.
Ensure that any bit fields have a default setup on sql server (usually 0)
Ensure that each table has a timestamp field.
This is important, espeically if you have any floating or "real" data type columns. The Access up-sizing wizard, and the migration tool for Access both by default suggest and will add the timestamp field.
If you missing any of the above 3 issues (that have been repeated over and over for the last 18 years on near every article about using SQL server.
So, you will ensure that you checked above all 3 issues.
After any table changes, you will re-link the access client side.
You then need to test/check if you can change edit data using the linked table directly from access (in table view). if you can edit such data directly, then you are back to testing with your form. If the form still causes a write conflict, then suggests in the article you linked to will START to apply, but not until such time you address and ensure all 3 above steps are issues are dealt with.
The time stamp is often required for a sub form, and also when you have real/floating columns. Due to rounding errors in such computer numbers, then the compare between the two records fail. The adding of the timestamp column fixes this issue since access now does not have to do a field by field compare, but will use the timestamp column (not to be confused with a datetime column) to figure out if record has been changed. Thus adopting this feature even reduces the network chatter from client to server and allows access to determine if server record been changed without having to resort to a field by field compare.
I recently encountered the same error and it turned out to be that I had an active sort on the datasheet view. Once I removed the sort, voila, problem solved! (Nothing like shooting myself in the foot.)
I updated the SCHEMA of a live table in MySQL for use in my multi-user database. Each user has their own db and links to the production tables through ODBC.
I have been receiving a write error while trying to test my schema updates. I cannot find the core reason. I hypothesized that because the other users are in the production table but have not been relinked to update the table SCHEMA; That it is causing a conflicting write error on my relinked table.
I added a TINYINT with No NULLS and default value of 0
I double checked all datatypes for incompatibility & have tested the "non relinked" tables in a older version of the DB and confirmed it is working as intended with no errors
I expect/want to be able to edit records without a write error, but am hesitant to update the other users to the new table if it is currently having write errors
After changing the schema of a linked table, it's required to refresh the link on all Access databases connected to it.
You can do this on the ribbon through external data -> linked table manager.
Unfortunately, either all users that have a database need to do this manually, unless you automate the task on startup through vba.
You have two separate issues. To "see" new columns, then yes, you must re-link the tables.
(so above is separate question and separate issue). You thus as a general rule can add new columns to the database (even while in use). However, the client side linked tables will not see the new columns until such time you re-link. This approach (adding new columns, but not yet re-linked from Access) is certainly ok and fine - the only downside is end users can't see nor use the new columns until such time you link. From a developer point of view, this good - since your users will not see nor find new columns until such time you roll out a new front end to each work station.
Ok, now problem and issue number two.
As for adding a new column, then re-linking, and THEN having some issue is really a separate issue. In most cases, if you attempting to use a tiny int as a Boolean (and I think that is your case), then you need to ensure several things:
Do not allow nulls (you seem to have this ok).
Make sure you set a default of 0 (server side) for this column. (you might have not allowed nulls, but without a default, then Access likely will still complain. And this default is important during creating time - since the new column needs to be "filled" with zeros.
Make sure the table has a PK defined.
Consider adding a row version column (I think mySQL has these, not sure but they can help immensely).
I'm not able to update values on tables present on my database using MySQL Workbench (or equivalent software such as Toad Edge):
The tables are read-only although primary key is present.
Only very few times the "read only" label is not present and MySQL Workbench lets me update table fields values, but if this occurs, as soon as I run another query (or if I run the same query twice), the "read only" label appears again.
This is all depends of the kind of query that you execute. If it's a simple one table query with simple WHERE command, then it should not be marked as "Read Only". However if the query contains an aggregation, group by or joins, then it will be marked as read only as trying to update the showed rows should be considered ambiguous.
At least Workbench allows editing on simple WHERE filters by default. Other IDEs, like SQLYog, marks any manually queried results as Read Only. However it could be overridden and it does an evaluation if it's safe to direct edit the data, if not, it stays as Read Only.
If this is not case, then it could be that the user that you are using to connect do not have UPDATE or INSERT rights.
I'm trying to lock a certain table (called gmd_settings) so it can't be modified anymore, but my lack of experience with MySQL and PHPMyAdmin plagues me. I need it explained to me how I would do this in simple terms, to someone that doesn't manage MySQL databases for a living.
To accomplish this, you should set up proper permissions. MySQL allows you to set permissions not only on a database and table level, but also on individual columns. If you create a new user (or edit the user you're using for this project) and set the permissions you desire, you can limit the user's ability to edit the gmd_settings table. Make sure you don't lock yourself out and I suggest that you make sure you understand what's happening rather than just copying the steps I outline. With that being said, here's what I would do:
Click on the Users tab and the Edit Privileges for the user you wish to edit (or Add a new user).
Near the top, look for the second level of tabs where you can select "Database":
Then select your database from the list and click Go:
Next, from the second level of tabs again click on "Table"
Now you have to add permissions for each table. From the dropdown select each table in turn and grant the proper set of permissions. For gmd_settings, that might be only SELECT, for the rest you'll probably at least also need INSERT and UPDATE. Again, these will depend on your configuration and specific needs; you should have some understanding of what you're doing here.
Hopefully that will get you where you want to be.
I am using the MySQL for Excel add-in. I have been using this for months to highlight a set of data and load it into my database.
I added a new table last week, and was successfully loading data into it using the same method. It stopped working. When I attempt to Append data, I get an error dialogue box that says "Cannot Find Column 30"...which happens to be the number (and therefore) last column in my table.
Some more information:
- If I highlight this same set of data and try to write it to another table, it will allow me to (even though I don't confirm and do it). I get past the error dialogue box to the Mapping dialogue box.
- I tried writing data from the previous table to this new problem table. I got the same error dialogue box.
This tells me that the problem is not with the data set. It is with the table.
I then deleted the table, all the connections and redid it from scratch. Still the same problem.
Where is this failing? Thank you.
ya even i had the same problem, even i tried the same way u did, like deleted the table recreated everything, it did not work, finally i tried to append some random table and went to "Advanced Options" at the bottom of the append pop up
in this u will see some "Stored Column mappings" and some mappings in it, now delete all of them and hit "Accept" now u can append the table
it will work
I know this is super old but I have a solution because it just happened to me.
Try append on different table. When box pops up click 'Advanced Options'
Then under column mapping uncheck both:
(Automatically store the column mapping for the given table) AND
(Reload stored column mapping for the select table automatically)
Then goto the Stored mappings tab and delete all the stored mappings
Click Accept and then rejoice you are free of that error for life.
best -J
If Excel does not show you the "Stored Column mappings" then connect to a MySQL table not used before in Excel, then retry the Append, the mapping will be shown. Then you can follow the answer provided by user3611272.
Problem will be resolved by doing below steps:
Select any table from Table other than your target table.
Click on Append Data
Press "Advanced Options"
Select tab "Stored Mappings"
Delete your target table mapping and Accept.
it will solve the issue.