I need to update around 1000 xml records with a new xml node, the xml's are stored in a sql table column, with xml datatype, So I've been trying to utilize the modify function documented HERE (specifically example A.4)
However, When I run this against my staging environment (SqlServer 2016 SP2-CU13) I receive the following error message:
Msg 2395, Level 16, State 1, Line 7
XQuery [production.dbo.organisations.Configuration.modify()]: There is no function '{http://www.w3.org/2004/07/xpath-functions}:AFTER()'
The code is rudimentary, I'm just stumped by the error message. Any help or insight is greatly appreciated
Code:
update [production].[dbo].[organisations] Set configuration.modify('INSERT <LegalEntityName>TEST</LegalEntityName> AFTER (/OrganisationMetaData/ExamPrepAssessModeFromAddress)[1]') where ID = 1
Remember XML is always case-sensitive, eg:
use tempdb
go
drop table if exists organisations
go
create table organisations(id int, configuration xml)
insert into organisations(id, configuration) values (1,'<OrganisationMetaData><ExamPrepAssessModeFromAddress></ExamPrepAssessModeFromAddress></OrganisationMetaData>')
update organisations Set configuration.modify('insert <LegalEntityName>TEST</LegalEntityName> after (/OrganisationMetaData/ExamPrepAssessModeFromAddress)[1]') where ID = 1
Related
I am using EF Core (3.1.15). In a previous migration (also created in 3.1.15), a column was referenced that was dropped later on. The idempotent script does check if the migration was performed on the database (which it is, and the reference still shows in the __EFMigrationsHistory table). However the check doesn't have the expected result and the script due to the inexistent column.
Q: why is the inexistent column tripping the execution of the SQL script?
Script was created with
dotnet-ef migrations script -i -o migrations.sql
Relevant part of the automated script that fails, where ReferenceToLedgerId is the column dropped in later migration:
IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20210612052003_CLedger')
BEGIN
UPDATE LedgerTable SET LedgerId = ReferenceToLedgerId
END;
Error:
Msg 207, Level 16, State 1, Line 3
Invalid column name 'ReferenceToLedgerId'
When running the following SQL query, the result comes back as expected:
SELECT *
FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20210612052003_CLedger'
MigrationId
ProductVersion
20210612052003_CLedger
3.1.15
The database is Azure SQL Database. Script doesn't fail on local SQL dev database. A dozen migrations have been applied since then, and only now the script fails.
Below was the call that created the specific script:
migrationBuilder.Sql("UPDATE LedgerTable set LedgerId = ReferenceToLedgerId", true);
I tried to place the table and column names in square brackets, but that made no difference (eg. [ReferenceToLedgerId]. The script fails in Azure DevOps release when using SQLCMD and also fails when using Azure Data Studio, both accessing the Azure SQL Database.
Additional check
I changed the script to do a quick check:
PRINT '#Before IF'
IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20210612052003_CLedger')
BEGIN
PRINT '#Within IF'
--UPDATE LedgerTable SET LedgerId = ReferenceToLedgerId
END;
PRINT '#After IF'
To which I get the following result:
Started executing query at Line 1
#Before IF #After IF
Total execution time: 00:00:00.010
If I uncomment the UPDATE statement it fails again. So I can only conclude that the code path works as intended, but that the server still checks for the existence of the column. I am not familiar with SQL to understand why this would be, or why it only fails for this one line while the column itself is referenced in other lines of the SQL script without it failing.
That batch will fail on every version of SQL Server. eg
use tempdb
go
create table __EFMigrationsHistory(MigrationId nvarchar(200))
create table LedgerTable(LedgerId int)
go
insert into __EFMigrationsHistory(MigrationId) values (N'20210612052003_CLedger')
go
IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20210612052003_CLedger')
BEGIN
UPDATE LedgerTable SET LedgerId = ReferenceToLedgerId
END;
Fails with
Msg 207, Level 16, State 1, Line 8
Invalid column name 'ReferenceToLedgerId'.
Because the batch cannot be parsed and compiled. It's simply not legal to reference a non-existent table or column in a TSQL batch.
You can work around this by using dynamic SQL, so that the batch referencing the non-existent column is not parsed and compiled unless the migration is being applied.
migrationBuilder.Sql("exec('UPDATE LedgerTable set LedgerId = ReferenceToLedgerId')", true);
This is documented here:
Tip
Use the EXEC function when a statement must be the first or only
one in a SQL batch. It might also be needed to work around parser
errors in idempotent migration scripts that can occur when referenced
columns don't currently exist on a table.
https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/operations
Using SQL Server 2016. Have a locally hosted database that uses the Windows login for the sa, which is what I am using to login.
Yesterday I ran
CREATE TABLE [Otis].[AnalyzerGroups]
(
[id] [int] IDENTITY,
[Name] [varchar](50) NULL
);
and got command successfully completed. Today I tried selected from this table but got an error:
Msg 208, Level 16, State 1, Line 1
Invalid object name 'Otis.AnalyzerGroups'
So I thought I misremembered and tried running the create statement again but then got the error -
Msg 15530, Level 16, State 1, Line 1
The object with name "AnalyzerGroups" already exists.
The statement has been terminated.
So then I tried DROP TABLE [Otis].[AnalyzerGroups]; and got
Msg 3701, Level 11, State 5, Line 1
Cannot drop the table 'Otis.AnalyzerGroups', because it does not exist or you do not have permission.
I tried making a new test table and the same thing. The first time I run the create statement command successfully completes, but then I can't select / insert / drop from the table, and I cannot see it in the Object explorer either.
I assume this must be some permissions issue but I don't know what property is keeping me from viewing these tables - its not like I'm putting security on these tables, and I can see every other table in our database. Any thoughts?
You put it most likely in the wrong database. Try this.
sp_MSforeachdb 'SELECT "?" AS DB, * FROM [?].sys.tables WHERE name like
''%AnalyzerGroups%'''
There was a trigger in the SQL Server database that fired any time a new table was created under any schema, and would then transfer it to the dbo schema. So my tables did exist, but they were under the schema I was expecting because of this trigger. Why does this trigger exist? Got me. But it's in production and has been for over a decade so there's some reason/it's definitely not changing. Thanks for the help though everyone.
I have a table in SQL that I can query easily when running SELECT * FROM Scheme.Table1
There are no Intellisense errors and I can see the table in the list of tables under the database
If I attempt to run an UPDATE against the table, I get the error
Msg 208 Invalid object name 'Table1'
Updates against other tabes within the same scheme all work fine
What could be causing this error? Is the wording misleading and it is really something else?
EDIT: update statement is...
UPDATE SCHEMA.TABLE1 SET SCH1 = 'DB', SCH2 = '1' WHERE MEMBERNO = 123999
All fields are correct and exist on the table
Thanks to the comments, it was a trigger on the table that was referencing itself without the SCHEMA (I was logged in using Windows Authentication)
When I try to run an insert statement like below on Azure SQL DW I always get the following error message
Msg 107085, Level 16, State 1, Line 1 107085;The query encountered a data consistency issue that prevents further execution. This issue could have been caused by use of non-deterministic operations in the query. Rewrite the failed query and re-execute it
insert into dbo.LoadLogs (Id, LoadDescription, RecordCount, LoadDate)
select newid() as Id, #LoadDescription, #RecordCount, #LoadDate;
The SQL DW service today doesn't support non-deterministic functions in DML statements. So your NEWID() call in the INSERT statement isn't supported (the error message is a bit misleading - we can improve that). Adding support is in our backlog. You can always file a request in our feedback forum:
https://feedback.azure.com/forums/307516-sql-data-warehouse
For now, you'll need to create a local variable for your GUID generations. Something like:
DECLARE #newidentifier UNIQUEIDENTIFIER;
SET #newidentifier = NEWID();
insert into dbo.LoadLogs (Id, LoadDescription, RecordCount, LoadDate)
select #newidentifier, #LoadDescription, #RecordCount, #LoadDate;
Check the content of our NewId(),also the datatype of all fields, and the value before insertion happen.
Maybe your ID is a primary key and auto incremental,your query is no longer happen and it can't be done.
Hope it helps.
I want to insert some data on the local server into a remote server, and used the following sql:
select * into linkservername.mydbname.dbo.test from localdbname.dbo.test
But it throws the following error
The object name 'linkservername.mydbname.dbo.test' contains more than the maximum number of prefixes. The maximum is 2.
How can I do that?
I don't think the new table created with the INTO clause supports 4 part names.
You would need to create the table first, then use INSERT..SELECT to populate it.
(See note in Arguments section on MSDN: reference)
The SELECT...INTO [new_table_name] statement supports a maximum of 2 prefixes: [database].[schema].[table]
NOTE: it is more performant to pull the data across the link using SELECT INTO vs. pushing it across using INSERT INTO:
SELECT INTO is minimally logged.
SELECT INTO does not implicitly start a distributed transaction, typically.
I say typically, in point #2, because in most scenarios a distributed transaction is not created implicitly when using SELECT INTO. If a profiler trace tells you SQL Server is still implicitly creating a distributed transaction, you can SELECT INTO a temp table first, to prevent the implicit distributed transaction, then move the data into your target table from the temp table.
Push vs. Pull Example
In this example we are copying data from [server_a] to [server_b] across a link. This example assumes query execution is possible from both servers:
Push
Instead of connecting to [server_a] and pushing the data to [server_b]:
INSERT INTO [server_b].[database].[schema].[table]
SELECT * FROM [database].[schema].[table]
Pull
Connect to [server_b] and pull the data from [server_a]:
SELECT * INTO [database].[schema].[table]
FROM [server_a].[database].[schema].[table]
I've been struggling with this for the last hour.
I now realise that using the syntax
SELECT orderid, orderdate, empid, custid
INTO [linkedserver].[database].[dbo].[table]
FROM Sales.Orders;
does not work with linked servers. You have to go onto your linked server and manually create the table first, then use the following syntax:
INSERT INTO [linkedserver].[database].[dbo].[table]
SELECT orderid, orderdate, empid, custid
FROM Sales.Orders
WHERE shipcountry = 'UK';
I've experienced the same issue and I've performed the following workaround:
If you are able to log on to remote server where you want to insert data with MSSQL or sqlcmd and rebuild your query vice-versa:
so from:
SELECT * INTO linkservername.mydbname.dbo.test
FROM localdbname.dbo.test
to the following:
SELECT * INTO localdbname.dbo.test
FROM linkservername.mydbname.dbo.test
In my situation it works well.
#2Toad: For sure INSERT INTO is better / more efficient. However for small queries and quick operation SELECT * INTO is more flexible because it creates the table on-the-fly and insert your data immediately, whereas INSERT INTO requires creating a table (auto-ident options and so on) before you carry out your insert operation.
I may be late to the party, but this was the first post I saw when I searched for the 4 part table name insert issue to a linked server. After reading this and a few more posts, I was able to accomplish this by using EXEC with the "AT" argument (for SQL2008+) so that the query is run from the linked server. For example, I had to insert 4M records to a pseudo-temp table on another server, and doing an INSERT-SELECT FROM statement took 10+ minutes. But changing it to the following SELECT-INTO statement, which allows the 4 part table name in the FROM clause, does it in mere seconds (less than 10 seconds in my case).
EXEC ('USE MyDatabase;
BEGIN TRY DROP TABLE TempID3 END TRY BEGIN CATCH END CATCH;
SELECT Field1, Field2, Field3
INTO TempID3
FROM SourceServer.SourceDatabase.dbo.SourceTable;') AT [DestinationServer]
GO
The query is run on DestinationServer, changes to right database, ensures the table does not already exist, and selects from the SourceServer. Minimally logged, and no fuss. This information may already out there somewhere, but I hope it helps anyone searching for similar issues.