Cannot update 'column'; field not updateable - ms-access

I have connected my application on visual studio using visual basic as programming language and MS Access as a database now when I want to save a new row in the database it is saying (Cannot update 'field1'; field not updateable)
And (column 'field1' does not allows nulls
I don't have any idea am still a beginner in visual basic and I am really blocked

Its likely field1 is an auto number field, and required field.
The first error-"(Cannot update 'field1'; field not updateable)" means the field's value are auto generated.
The second error-"And (column 'field1' does not allows nulls)" means the required property of the field in the table is set to true.
So go to the ms access database and check for the following
The field type (likely an auto number or auto generated)
The required property section of the field, check to be sure its not set to yes.
You might need to share more details like how are you updating the record set from visual studio.

Related

Maintaining AutoNumber functionality in a form while using SQL backend

Currently, I am trying to move from an Access backend to a SQL backend for my database while still keeping the Access form as the frontend. This is done via linked tables with ODBC connections to my backend. The form is designed to add new records to the table. The problem is with AutoNumber. The ID was set as an AutoNumber and the form would simply display (New) while waiting for the user to add the remaining columns. I have set up my SQL data with the IDENTITY property, so it will increment once a new record is created. However, I cannot get the form to behave the same way as it did because, even though the backend will automatically add the next sequential ID, I cannot automatically fill that data into the form prior to a user actually saving the form data. Is there a way maintain the form functionality that AutoNumber provides?
TL;DR: Form is not working correctly after AutoNumber is changed to Number.
Well, there are "rare" cases in which you actually need the autonumberr before you save the record. For example, if you have a sub-form, then Access ALWAYS does a automatic save of the main record, and thus the autonumber is and will have been created .So a main form, and sub form (child table) will work fine, and do so without code.
Now, there are some cases in which you need the autonumber. Say you have some "code" that needs to run and spit out some child records.
The general approach is to simply execute a record save at that point in time.
So, say there is a button, or some code you need to run in the form, and you NEED the PK autonumber?
You can use this code:
If isnull(me!ID) = true then
me.dirty = false ' force record save - autonumber now created
end if
the record for above to work will have to be "dirty", but in near all cases, this tends to be the case. The "rare" exceptions would suggest that you could check me.IsNewRecord, but in most cases the above bit of code will suffice.
I can't really imagine that the "display" of some autonumber is oh so important WHEN the user is starting to enter data.
However, if you want the autonumber to appear after ANY keypress (data entry on the form)?
Simply put this line of code in the after insert event:
me.dirty = false
So, now when looking at a form, the FIRST key press by the user in any text box will force the autonumber to be generated and appear. However, it is a VERY bad practice to assign any meaning of the autonumber ID to the end users. In fact that ID should in most cases be hidden.
the only issue or downside of above is of course that if you have any required columns, then the above may error out or case an issue.
Solution
For this problem, I needed to set my identity_insert to ON in the SQL backend. Here is the code to do so:
SET IDENTITY_INSERT tableName ON;
Also, if you get the error: Table <Table Name> does not have the identity property. recreate the table with the autoincrementing column having an identity.
Example:
CREATE TABLE new_employees (id_num int IDENTITY(1,1), fname varchar (20), minit char(1), lname varchar(30));
More on IDENTITY in Microsoft offical documentation: here

How to make the default value a reference to a field from another table while still being able to edit the new field in Microsoft Access?

How to make the default value a reference to a field from another table while still being able to edit the new field in Microsoft Access?
Ideally, I’d like to find a solution that doesn’t include the use of VBA coding.
If you have Access 2010 or 2013 you can use the macro event "After Insert Macro Event"
Here is the official description from Microsoft
https://msdn.microsoft.com/en-us/library/office/ff196099(v=office.14).aspx
You should examine the Example and build an appropriate version in your database for your needs.

Data type conversion from Access to SQL Server errors

I have a SQL Server that is ODBC into my Access which is being utilized as my front end. I created a column in SQL with a BIT data type and created a checkbox with the yes/no data type that uses my SQL Column as its control source. When I go into my form and try to change anything in there and update my tables, I get a writing error and it wont let me append the updates I'm trying to make. As soon as I delete the bit data type, and the check box, then I am able to again append information to my form. Does anyone know a solution or a way I could utilize the Boolean check boxes to report to my SQL Database so that I could track progress of an order, but still be able to append my records? Also if anyone knows why this is happening I would appreciate the information just for my own notes and understanding.
this image shows the column created in SQL Server
This image shows what it looks like in the ODBC table in Access
This image shows the control source I picked which is from a query that utilizes the names of the form comboboxes, text boxes, and hopefully check boxes
This is image shows what happens after I try to update and and close
Thanks
haven't done this for a long time, but the problem could be related to the numbers that are stored. yes/no in access = -1/0, in sqlsrvr = 1/0 (or similar). you could use an INT field in sqlsrvr which will then store whatever access sends (-1 or 0), or keep the BIT but don't use yes/no in access - create a custom yes/no table where yes=1 and no=0 (or whatever BIT needs) and use the custom table as a lookup table for that field which, when updated will send the appropriate value. hope that's all relevant and makes sense.
So I have been messing around with this and after a few other problems running through SQL, Cabinet Vision (our drafting software with a ancient access database) and crystal reports I came to realize that Access cannot accept null values.
So in my SQL Bit data type column I set the default value as 0 and didn't allow nulls. now it records all my check boxes as true or false. and I no longer have a write conflict.
This most commonly arises when a db is developed in Access and at some later date the tables are exported via ODBC to SQLServer. The Checkbox controls on the Access forms were probably placed there using the 'Available Fields' button on the Access 'Design' ribbon. Before getting into complicated solutions with T-SQL modifications to metadata etc, try simply deleting the checkbox control from the problem Access form. Insert an unbound checkbox to replace it, then use the the Properties dialog to set the relevant SQLServer field as the control source for that checkbox. Usually works.

How to get the GUID of a table in microsoft Access

In Access, when I do a Database Tools->Database Documenter, and document an existing table, the report has a value called GUID. I want to get that GUID programatically.
I am trying to determine if 2 databases came from the same source, by comparing their GUID.
Points for either telling me the name of the function; alternately, you could tell me how to decompile the code that generates the report.
At least on Access 2010, the GUID value is in the "Properties" section of the Database Documenter report, so I tried this out in one of my databases:
CurrentDB.TableDefs("dateTest").Properties("GUID").Value
The return value is an Array of Bytes.
The value can be found in the system table called MySysNameMap
SELECT GUID FROM MySysNameMap WHERE Name = "Your TABLE NAME"
You can also use function such as DLookup in VBA to get the GUID from that system table.

Access Validation Rule Violations on Append Query

I'm recieving the following error on trying to run an append query in access.
Microsoft Office Access set .... and it didnt't add... 779280 records(s) due to validation rule violations.
If I choose to run the query anyways, nothing actually happens.
To give some context, I'm simply trying to copy a populated field, consisting of values similar to "16-2009-02, 34-2010-02, et cetera" to another currently unpopulated field.
The fields themselves have no set validation rules, and both have the standard text field options.
I'm hoping to be able to simply remove those hyphens, and fix the issue. But I guess that's what I'm not sure about, are those hyphens actually a problem?
Running SP3 w/ Access 2003.
Thanks in advance!
Does the destination field have Allow Zero Length set to false or Required set to true? If it does, it is possible that some of the data from the source column is null or is set to an empty string. In addition, you should verify that the field sizes on the new column is equal to larger than the source column.
EDIT On appending from one table to another, you must ensure that you populate the columns that makeup the primary key of the destination table. Thus, from your screenshot, you need to include the loggerid and datetime columns from the "Log ID" table. Now, if there are collisions, Access should tell you how many rows generated collisions and let you append the ones that did not collide with the uniqueness restriction on loggerid and datetime
Make sure the target column is not indexed or, if it is, that duplicates are allowed. Access often makes indexing decisions on your behalf and sometimes they are not correct.