I have an Access 2010 'front-end' DB that has its data stored in a SQL Server DB 'back-end.'I'm trying to write the most simple UPDATE query I can and being met with this error: 'Operation must use an updateable query.' My qry code is:
UPDATE tblTableLastModifiedDates SET LastModified = NOW()
WHERE id='1';
A lot of this DB was set up before I got this job so the dumb table names are not my fault. Also, I checked the tblTableLastModifiedDates and it actually has no PK and I've been unable to create one. I'm not sure if that is the problem.
Before I scrap all this and start it over (to do it the right way), I figured I'd ask if anyone knew how to fix this error.
This error implies that tblTableLastModifiedDates is a view that is not unique enough to update the LastModified field in the underlying table. This isn't that uncommon.
The best approach is going to be to execute the UPDATE against the underlying table.
Related
I'm trying to clear out a lot of clutter in various databases on a SQL Server that were left behind by some sloppy prior employees. My boss is afraid to let me delete unused tables because he believes it might not generate an error message, but might simply cause wrong data to be returned. I don't see how; if a table is joined in a SQL statement and the table doesn't exist, I can't imagine it not raising an error. Is this possible?
In normal circumstance you'd always get an error, however these may not be normal circumstances.
It's unlikely, but if you have procedures building dynamic SQL using the information_schema views to get table names you could potentially write some SQL that fails silently if the table isn't there
It's technically possible depending on how you access the data and how any stored procedures querying said table were written. E.g. if there are TRY CATCH blocks in your T-SQL, it could be possible. But that's just theoretical. In practice, you'll get real ugly errors if you delete a table.
What I would do in the interim is rename the table and then run every unit test and integration test you can find. If something references the table, rename it back to what it was, otherwise dump it.
We had another developer come through and complete some work for us. Unfortunately he didn’t work well within our team and management let him go.
Because of this now I’m stuck debugging his code and undoing work that was done. He did not document his code (one of the reasons he was let go), rarely notating anything, therefore I have no idea where to begin looking.
When I run a basic SELECT on two specific tables in our DB:
SELECT * FROM table_name
Using SQL Server Management Studio I get this...
Msg 207, Level 16, State 1, Line 1
Invalid column name 'eventTime'.
There was an eventTime column but wasn’t necessary and wasn't being used in any PHP file, however it seems somehow directly tied to the table now and I have no idea where to look to find it. The error message provided is pointing to my SELECT statement, but there is nothing wrong with it, nor does it even reference the eventTime column.
I’ve looked and there don’t seem to be any triggers or stored procedures referencing this table. Is there another way I can try to track this down?
This sounds like a hard'ish problem. Here are some ideas.
My first thought is that table_name is a view, and somehow the view has gotten out-of-sync with the underlying table definitions. I have seen problems with types in some circumstances. I imagine the same could happen with column names.
The next thought is that table_name has computed columns. In this case, the computed columns could be using a function and the function call could be generating the error. I cannot think of any other way to run code with a simple select.
I don't think the problem would be a foreign key constraint unless. So, a third option is that a foreign key constraint is referencing a table in the same database but a different schema. The different schema could have permissions that make the table inaccessible.
For any of these, scripting out the definition in SSMS will help you fix the problem.
I was given a database by a client. I can't access any of the data in the Views in this database because I get this error:
Invalid object name 'DWView.dbo.Person_C'.
I have no user/role/anything called DWView. The view exists, but nothing can access it. This happens in all of the views.
One thing I'm not clear on -- what is DWView.dbo? I know dbo is the schema/owner, but what about the DWView part? I've never encountered this in 15+ years of working with MSSQL databases.
Any attempt to access the views fails with that error, including sp_refreshview.
Is there anything I can do to remove this DWView thing? Thanks.
The error means the object doesn't exist. Like you mentioned, the schema comes before the view in syntax; so when you ask ...
One thing I'm not clear on -- what is DWView.dbo
... it means database.schema. So your query is looking for the database DWView, the schema dbo, and the object name Person_C.
As a note, if you're already on the database (USE Database GO), you don't have to use the database in your query; you can simply use SchemaName.ObjectName.
Try executing this ..
USE Your_Database_Name
GO
SELECT * FROM dbo.Person_C
GO
It should be [database].[schema].[objectname].
I need to create a saved MS Access query from within my VB.net program using OleDb. But before I create the query I need to check and see if it already exists in the database. If it does exist I want to update it. How do I check for an existing query in MS Access using OleDb?
"If it does exist I want to update it."
Based on the comment discussion, I understand you will execute a statement on the OleDB connection to create the query. (In Access parlance, a QueryDef object.)
When the query does not already exist, the execute succeeds and you're done.
If the query does exist, the execute attempt will throw an error which you will trap in your VB.Net code. At that point, you want to revise the existing query. Unfortunately, I don't know any way to alter an existing query with OleDb. You can however discard the existing query and re-execute your statement to create the new version.
You can execute an Access DDL statement to discard the existing query. One of these two versions will do what you need:
DROP VIEW YourQueryNameHere;
DROP PROCEDURE YourQueryNameHere;
The first is for plain SELECT queries. The second is for what Access calls "action queries": INSERT; UPDATE; DELETE. A "make table" query (SELECT <field list> INTO NewTable FROM ...) also falls into the second (PROCEDURE) category as I recall (check to confirm if you need it). I think a SELECT query with PARAMETERS also falls into that second category (check if needed).
Note this is a only a suggested direction. I can't offer you VB.Net code. And I'm hopeful you know or can figure how to do the required error-handling in VB.Net.
I have lost a trigger. I know it is active, since when I try to change a field, it restores its value back, and from the SQL Server Management Studio I can see that when I execute the query, an extra one is executing (the trigger one).
I tried SELECT * FROM sys.triggers WHERE 1 = 1 but it does not return anything. Also, I know the name of the trigger, but when I try to ALTERit returns an error saying that
the name of the object 'myTrigger' is not valid.
And if I try to DROP TRIGGER myTrigger ON DATABASE
Trigger 'myTrigger' can not be removed because it does not exists, or the user has not enough priviledges.
Ok, as Lieven said, I was not querying the right database... This is odd, since the query had the DB defined on it
ALTER TRIGGER myTrigger
ON [DB].[dbo].[table]
But the upper select of the SQL Server Management Studio was pointing to other DB...
Edit:
I have been investigating a little bit (trying to clean my image), and I found a weird behaviour on SQL Server Management Studio.
If you execute a query like:
UPDATE [DB].[dbo].[table] SET column = 'value' WHERE column2 = 'foo'
It executes the query in the right DB. No matter what DB is pointed by the upper select.
But, if you try to do the same, with a trigger, you must have the upper select pointing the right DB, or you will face the same problems I had.
I had a subtle error kind of like yours; I did something like this:
CREATE TRIGGER [TrigCustomerInsertDelete]
ON [mobile].[Customers]
AFTER INSERT, DELETE
AS
select 'I' [ACTION],* from inserted
select 'D' [ACTION],* from deleted
GO
and then later tried to update it with:
ALTER TRIGGER [TrigCustomerInsertDelete]
and got this error: Invalid object name
The problem was that I did not specify the schema on the trigger (thinking it would just be dbo), but the table does have a schema. So, I figured out the error after including the schema on the trigger.
CREATE TRIGGER [DBO].[TrigCustomerInsertDelete]
This gave me the following error: Cannot create trigger 'DBO.TrigCustomerInsertDelete' because its schema is different from the schema of the target table or view.
I know this is an old post, but hopefully it will help someone else.