I created a table in MS-Access 2010 by running the following script on SQL server 2008
SELECT * into qryInstrumentInterfacelog FROM tblInstrumentInterfaceLog
qryInstrumentInterface is used to populate a subform on the main form. After a "Process" button is pressed, files are read in and stored in the database. tblInstrumentInterface will be inserted with a new record everytime a new file is read in. My problem is qryInstrumentInterfacelog will not update with tblInstrumentInterfaceLog, it will just keep the same data it had when the script was first ran on the server. I have tried different methods to requery the subform but I realized the subform had no issues it was the actual table that wasn't changing. How can I get qryInstrumentInterfacelog to be dynamic and update as tblInstrumentInterfaceLog updates? Is my SQL code wrong?
Well, one important concern is that, indeed, you cannot repeat the query as written.
"Select... into" creates a new table only. It does not insert/append to such a table.
So if you are really calling that a second time, it is probably erroring out.
If you really want to drop and replace the table, make sure to call an explicit "Drop Table" in advance of your "Select...Into".
--
A typical pattern, in SQL Server t-sql, is
if object_id('*your_table_name*') is not null
drop table *your_table_name*
;
*...your select...into*
a problem has come up after a SQL DB I used was migrated to a new server. Now when trying to edit a record in Access (form or table), it says: WRITE CONFLICT: This record has been changed by another user since you started editing it...
Are there any non obvious reasons for this. There is noone else using the server, I've disabled any triggers on the Table. I've just found that it is something to do with NULLs as records that have none are ok, but some rows which have NULLs are not. Could it be to do with indexes? If it is relevant, I have recently started BULK uploading daily, rather than doing it one at a time using INSERT INTO from Access.
Possible problems:
1 Concurrent edits
A reason might be that the record in question has been opened in a form that you are editing. If you change the record programmatically during your editing session and then try to close the form (and thus try to save the record), access says that the record has been changed by someone else (of course it's you, but Access doesn't know).
Save the form before changing the record programmatically.
In the form:
'This saves the form's current record
Me.Dirty = False
'Now, make changes to the record programmatically
2 Missing primary key or timestamp
Make sure the SQL-Server table has a primary key as well as a timestamp (= rowversion) column.
The timestamp column helps Access to determine if the record has been edited since it was last selected. Access does this by inspecting all fields, if no timestamp is available. Maybe this does not work well with null entries if there is no timestamp column (see 3 Null bits issue).
The timestamp actually stores a row version number and not a time.
Don't forget to refresh the table link in access after adding a timestamp column, otherwise Access won't see it. (Note: Microsoft's Upsizing Wizard creates timestamp columns when converting Access tables to SQL-Server tables.)
3 Null bits issue
According to #AlbertD.Kallal this could be a null bits issue described here: KB280730 (last snapshot on WayBackMachine, the original article was deleted). If you are using bit fields, set their default value to 0 and replace any NULLs entered before by 0. I usually use a BIT DEFAULT 0 NOT NULL for Boolean fields as it most closely matches the idea of a Boolean.
The KB article says to use an *.adp instead of a *.mdb; however, Microsoft discontinued the support for Access Data Projects (ADP) in Access 2013.
Had this problem, same as the original poster. Even on edit directly using no form. The problem is on bit fields, If your field is Null, it converts Null to 0 when you access the record, then you make changes which this time is the 2nd change. So the 2 changes conflicts. I followed Olivier's suggestion:
"Make sure the table has a primary key as well as a timestamp column."
And it solved the problem.
I have seen a similar situation with MS Access 2003 (and prior) when linked to MS SQL Sever 2000 (and prior). In my case I found that the issue to be the bit fields in MS SQL Server database tables - bit fields do not allow null values. When I would add a record to a table linked via the MS Access 2003 the database window an error would be returned unless I specifically set the bit field to True or False. To remedy, I changed any MS SQL Server datatables so that any bit field defaulted to either 0 value or 1. Once I did that I was able to add/edit data to the linked table via MS Access.
I found the problem due to the conflict between Jet/Access boolean and SQL Server bit fields.
Described here under pitfall #4
https://blogs.office.com/2012/02/17/five-common-pitfalls-when-upgrading-access-to-sql-server/
I wrote an SQL script to alter all bit fields to NOT NULL and provide a default - zero in my case.
Just execute this in SQL Server Management Studio and paste the results into a fresh query window and run them - its hardly worth putting this in a cursor and executing it.
SELECT
'UPDATE [' + o.name + '] SET [' + c.name + '] = ISNULL([' + c.name + '], 0);' +
'ALTER TABLE [' + o.name + '] ALTER COLUMN [' + c.name + '] BIT NOT NULL;' +
'ALTER TABLE [' + o.name + '] ADD CONSTRAINT [DF_' + o.name + '_' + c.name + '] DEFAULT ((0)) FOR [' + c.name + ']'
FROM
sys.columns c
INNER JOIN sys.objects o
ON o.object_id = c.object_id
WHERE
c.system_type_id = 104
AND o.is_ms_shipped = 0;
This is a bug with Microsoft
To work around this problem, use one of the following methods:
Update the form that is based on the multi-table view
On the first occurrence of the error message that is mentioned in the "Symptoms" section, you must click either Copy to Clipboard or
Drop Changes in the Write Conflict dialog box. To avoid the repeated
occurrence of the error message that is mentioned in the "Symptoms"
section, you must update the recordset in the form before you edit
the same record again.
Notes
To update the form in Access 2003 or in Access 2002, click Refresh on the Records menu.
To update the form in Access 2007, click Refresh All in the Records group on the Home tab.
Use a main form with a linked subform
To avoid the repeated occurrence of the error message that is mentioned in the "Symptoms" section, you can use a main form with a
linked subform to enter data in the related tables. You can enter
records in both tables from one location without using a form that is
based on the multi-table view.
To create a main form with a linked subform, follow these steps:
Create a new form that is based on the related (child) table that is used in the multi-table view. Include the required fields
on the form.
Save the form, and then close the form.
Create a new form that is based on the primary table that is used in the multi-table view. Include the required fields on the
form.
In the Database window, add the form that you saved in step 2 to the main form.
This creates a subform.
Set the Link Child Fields property and the Link Master Fields property of the subform to the name of the field or fields that are
used to link the tables.
Methods from work around taken from microsoft support
I have experienced both of the causes detailed above: Directly changing data in a table that is currently bound to a form AND having a 'bit' type field in SQL Server that does not have the Default Value set to '0' (zero).
The only way I have been able to get around the latter issue is to add the default value of zero to the bit field AND run an update query to set all current values to zero.
In order to get around the former error, I have had to be inventive. Sometimes I can change the order of the VBA statements and move Refresh or Requery to a different location, thus preventing the error message. In most cases, however, what I do is DIM a String variable in the Subroutine where I call the direct table update. BEFORE I call the update, I set this String variable to the value of the Recordsource behind the bound form, thus capturing the exact SQL statement being used at the time. Then, I set the form's Recordsource to an empty string ("") in order to disconnect it from the data. Then, I perform the data update. Then, I set the form's Recordsource back to the value saved in the String variable, reestablishing the binding and allowing it to pick up the new value(s) in the table. If there is one or more subforms contained within this form, then the "Link" fields need to handled in a similar manner as the Recordsource. When the Recordsource is set to an empty string, you may see #Name in the now-unbound fields. What I do is simply set the Visible property to False at the highest possible level (Detail section, Subform, etc.) during the time when the Recordsource is empty, hiding the #Name values from the user. Setting the Recordsource to an empty string is my go-to solution when a coding change can't be found. I am wondering, though, if my design skills are lacking and there is a way to completely avoid the issue altogether?
One final thought on addressing the error message: Instead of calling a routine to directly update the data in the table table, I find a way to update the data via the form instead, by adding a bound control to the form and updating the data in that so that the form data and the table data do not become out of sync.
In order to get over this problem. I created VBA to change another field in the same row. So I created a separate field which adds 1 to the contents when I try to close the form. This solved the issue.
I've dealt with this issue with MS Access tables linked to MS SQL tables multiple times. The original poster's response was extremly helpful and was indeed the source of much of my issues.
I also ran into this issue when i accidently added a bit field with a space in the fieldname... yeah....
I had run alter table tablename add [fieldname ] bit default 0. i solution i found was to drop that field and not have a space in the name.
I had this issue and realized it was caused by adding a new bit field to an existing table. I deleted the new field and everything went back to working fine.
If you are using linked tables, ensure you have updated these and retry before doing anything else.
I thought I had updated them but hadn't, turns out someone had updated the form validation and SQL tables to allow 150 chars, but hadn't refreshed the linked table hence access only saw 50 char allowed - Boom Write conflict
Not sure this is the most appropriate error for the scenario, but hey, most of the interesting issues are never flagged appropriately in any microsoft software!
I´m using this workaround and it has worked for me:
Front end: Ms Access
Backend: Mysql
On the Before update event of a given field:
Private Sub tbl_comuna_id_comuna_BeforeUpdate(Cancel As Integer)
If Me.tbl_comuna_id_comuna.OldValue = Me.tbl_comuna_id_comuna.Value Then
Cancel = True
Undo
End If
End Sub
I just had very havy write-conflict problems (Acc2013 32bit, SQL Srv2017 expr) with a rather "heavy loaded" Split-Form.
For me - at last - was the solution to get rid of the write-conflict problems to simply
SET THE AcSplitFormDatasheet to READ-ONLY !!! (I haven't a clue why it was read-write anyway i must have set it by fault...)
It did nearly cost me a whole week to find that out.
I was having this problem and saving the record, marking Dirty to false, etc. did not work. It ended up that adding a timestamp column to the SQL table is what avoided/fixed the issue.
When last time I got this error, it was bit field having NULL value issue.
But this time, it was different text size of source table field vs linked table field.
I checked all my bit fields in various tables but didn't find any issue. All of them had default value, so there were no NULL values for bit fields. I observed that a text field with nvarchar(500) was giving this error. The linked table was using old field size 50 instead of recently changed 500. Relink of tables solved the problem.
So another finding is if the data type is changed for a linked table, you need to relink the table.
Just had this issue on MS Access 365 connected to PostgreSQL server. The error only occurred when trying to edit the first row.
I manually deleted the first row in pgAdmin 4, and then manually added it again. This solved the issue.
I was receiving the same error message.
Id Column in database table was set to BigInt, changing it to Int resolved the issue.
I'm slowly learning SQL and how to use form builder 6. The situation is I have a simple table named 'players' within the table I have three columns:
player_no (primary key)
position
goals
Within form builder 6 I have created a very simple form using these three fields. The form is named 'TEAM'. At at the foot of the form I have a button labelled 'Add'. The goal is for the user to enter a player_no, position and goals and then to click 'Add'. This information is then to go into my table.
All attempts so far have failed miserably. I have set up a trigger on the button (WHEN_MOUSE_CLICK). I have then entered the following code:
BEGIN
INSERT INTO players ( player_no )
VALUES ( :TEAM.player_no )
END
For the purpose of testing it out I have only been using the one (player_no) field. This then compiles with no errors yet when I run the form and enter a player_no and hit the button I get the following error in the status bar:
frm-40735: WHEN-MOUSE-CLICK trigger raised unhandled exception ORA-01400
Am I doing something horribly wrong? I am very much new to SQL and Form Builder so any help would be greatly appreciated.
ORA-01400: cannot insert Null seems like one of your fields are not null and you omited them on insert. or value :TEAM.player_no is null during insert.
Also, somewhere from web:
FRM-40735: ON-INSERT trigger raised
unhandled We have had similar problem
since 11.5.9. We clear Jinitiator
cache, and temporary internet files
(tools>internet options then under
temporary internet files the clear
files button). Seems to work.
One of the benefits of using Form Builder is that you almost always don't need to write the DML statements yourself.
Just make the block based on the table - then the user can add and modify as many records as they like, then when they save (i.e. COMMIT), the Forms runtime automatically works out what INSERTs and UPDATEs are required to save the changes.
This question is very similar to SQL Server 2005: T-SQL to temporarily disable a trigger
However I do not want to disable all triggers and not even for a batch of commands, but just for one single INSERT.
I have to deal with a shop system where the original author put some application logic into a trigger (bad idea!). That application logic works fine as long as you don't try to insert data in another way than the original "administration frontend". My job is to write an "import from staging system" tool, so I have all data ready. When I try to insert it, the trigger overwrites the existing Product Code (not the IDENTITY numeric ID!) with a generated one. To generate the Code it uses the autogenerated ID of an insert to another table, so that I can't even work with the ##IDENTITY to find my just inserted column and UPDATE the inserted row with the actual Product Code.
Any way that I can go to avoid extremly awkward code (INSERT some random characters into the product name and then try to find the row with the random characters to update it).
So: Is there a way to disable triggers (even just one) for just one INSERT?
You may find this helpful:
Disabling a Trigger for a Specific SQL Statement or Session
But there is another problem that you may face as well.
If I understand the situation you are in correctly, your system by default inserts product code automatically(by generating the value).
Now you need to insert a product that was created by some staging system, and for that product its product code was created by the staging system and you want to insert it to the live system manually.
If you really have to do it you need to make sure that the codes generated by you live application in the future are not going to conflict with the code that you inserted manually - I assume they musty be unique.
Other approach is to allow the system to generate the new code and overwrite any corresponding data if needed.
You can disable triggers on a table using:
ALTER TABLE MyTable DISABLE TRIGGER ALL
But that would do it for all sessions, not just your current connection.. which is obviously a very bad thing to do :-)
The best way would be to alter the trigger itself so it makes the decision if it needs to run, whether that be with an "insert type" flag on the table or some other means if you are already storing a type of some sort.
Rather than disabling triggers can you not change the behaviour of the trigger. Add a new nullable column to the table in question called "insertedFromImport".
In the trigger change the code so that the offending bit of the trigger only runs on rows where "insertedFromImport" is null. When you insert your records set "insertedFromImport" to something non-null.
Disable the trigger, insert, commit.
SET IDENTITY_INSERT Test ON
GO
BEGIN TRAN
DISABLE TRIGGER trg_Test ON Test
INSERT INTO Test (MyId, MyField)
VALUES (999, 'foo')
ENABLE TRIGGER trg_Test ON Test
COMMIT TRAN
SET IDENTITY_INSERT Test OFF
GO
Can you check for SUSER_SNAME() and only run when in context of the administration frontend?
I see many things that could create a problem. First change the trigger to consider multiple record imports. That may probably fix your problem. DO not turn off the trigger as it is turned off for everyone not just you. If you must then put the database into single user user mode before you do it and do your task during off hours.
Next, do not under any circumstances ever use ##identity to get the value just inserted! USe scope_identity instead. ##identity will return the wrong value if there are triggers onthe table that also do inserts to other tables with identity fields. If you are using ##identity right now through your system (since we know your system has triggers), your abosolute first priority must be to immediately find and change all instances of ##identity in your code. You can have serious data integrity issues if you do not. This is a "stop all work until this is fixed" kind of problem.
As far as getting the information you just inserted back, consider creating a batchid as part of you insert and then adding a column called batchid (which is nullable so it won't affect other inserts)to the table. Then you can call back what you inserted by batchid.
If you insert using BULK INSERT, you can disable triggers just for the insert.
I'm pretty sure bulk insert will require a data file on the file system to import so you can't just use T-SQL.
To use BULK INSERT you need INSERT and ADMINISTRATOR BULK OPERATION permissions.
If you disable triggers or constraints, you'll also need ALTER TABLE permission.
If you are using windows authentication, your windows user will need read access from the file. if using Mixed Mode authentication, the SQl Server Service account needs read access from the file.
When importing using BULK IMPORT, triggers are disabled by default.
More information: http://msdn.microsoft.com/en-us/library/ms188365.aspx