I am trying to restore a SQL Server 2014 database in SQL Server 2005. I am doing by generating the complete script (with schema and data) from SQL Server 2014.
I get an error saying
'INSERT failed because the following SET options have incorrect settings: 'ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods.'
and
'Cannot insert explicit value for identity column in table 'T_GASAdminNote' when IDENTITY_INSERT is set to OFF.'
I have searched for solution but have not been able to rectify the problem. I have tried the solution given in this link, but it didn't help me.
Can anyone suggest me some solutions for restoring the database.
Update: sorry - misread your question...
The first error means just that - for some operation you're trying to do, your SET ANSI_PADDING setting is wrong. Read the official documentation on ANSI_PADDING on MSDN to learn more about this setting. Check what your setting is now - obviously, if that error occurs, you need the other setting for that operation you're attempting to do.
The second error means that your table T_GASAdminNote has an identity column, and you're trying to insert values into that column, but without first enabling this by using SET IDENTITY_INSERT T_GASAdminNote ON (and don't forget to disable the option after you're done!)
Related
I'm using Crystal Reports 2008 with SQL Server 2014.
I read on the internet that it was possible to create a temporary table with Crystal Reports. This link says that, one of many examples -> Click here
Yet when I go to the database expert, create a new command and enter the following DDL
CREATE TABLE #temp_test (col1 VARCHAR(5))
I get this error
Translation:
database connector error : 'No error message from server'
Yet, when I'm doing that with SQL Server on my database, everything is fine.
Have you managed to do it? If yes, how?
It sounds like an urban legend to me but I might be wrong...
Cheers
When you create a "Command" table in Crystal, you're giving Crystal a set of text to send to the SQL server, and Crystal expects a data set in return. Everything in between is done on the SQL server. Crystal checks the command by sending it to the SQL server when you enter it to see if it works.
Given that, your temp table is actually created on the SQL server. Also, when you create a temp table, it is deleted after the command is finished running.
As a result, if you use only this code, the SQL server will create the table, but there is no data set to return. It succeeds, so doesn't return an error, but also doesn't return data, hence the message: "No error message from server".
For your next step, I would suggest using code like this:
CREATE TABLE #temp_test (col1 VARCHAR(5))
SELECT * FROM #temp_test
This will create an empty data set to return to Crystal, so that it's getting the response it needs. I say this so that you don't think anything is wrong when you don't see anything. You'll need to insert data into the temp table in order to get it from the select statement for visual confirmation.
I would also suggest that you don't use a temp table unless you determine that you do or will actually need one within the scope of the command. For example, you may need one to increase performance on a particularly complex query or CTE, so it might increase performance to use a temp table. But I would create that query first and worry about optimization after I have at least some of it developed.
I have SQL server and SQL management studio 2012. After i create tables and when i export the data base to the server "online" every "primary and auto incremental" field become as a normal field. so when i try to add row to database i have the following error
"Cannot insert the value NULL into column 'taskID', table 'lawyersDB.dbo.tasks'; column does not allow nulls. INSERT fails.
The statement has been terminated."
To solve this problem i have to manage the database "online" and go to each table and set again the fields primary and auto incremental. Since i have many tables, this process takes lot of time.
So Any idea to solve this problem!?
Note: my hosting is on Arvix company server
This is SQL Management Studio, not your account.
Try this:
You need to set this, or else if you have a non-nullable column, with no default error, if you provide no value it will error.
To set up auto-increment in SQL Server Management Studio:
Open your table in Design
Select your column and go to Column Properties
Under Indentity Specification, set (Is Identity)=Yes and Indentity Increment=1
I understood that setting a database to a COMPATIBILITY_LEVEL prior to your native one prevented features from being used. However this doesn't seem to be the case. Witness the following SQL script:
CREATE DATABASE Foo
GO
USE Foo
GO
ALTER DATABASE Foo SET COMPATIBILITY_LEVEL = 80
GO
CREATE TABLE Bar
(
Id UNIQUEIDENTIFIER NOT NULL,
TestNvcMax NVARCHAR (MAX) NOT NULL, -- Arrived in SQL 2005
TestDateTime2 DATETIME2 (7) NOT NULL -- Arrived in SQL 2008
)
GO
But this table creates perfectly - any ideas? I would have thought some kind of an error message or warning would have been appropriate
Here you can read about the differences between compatibility level 80, 90 and 100. ALTER DATABASE Compatibility Level
Apparently new data types is not affected. I think that compatibility level is there to make SQL Server "behave" like the older version, not prevent you from doing new fancy stuff.
BOL says:
Compatibility level provides only
partial backward compatibility with
earlier versions of SQL Server.
Also:
New functionality might work under
older compatibility levels, but SET
options might require adjustments.
I believe that is your case.
I understand this is an old post, but for anyone else who ends up here as I did, more information is always helpful.
It could also be that the new compatibility did not take effect before running the create table statement.
"The new compatibility setting for a database takes effect when a USE Database is issued or a new login is processed with that database as the default database."
(https://msdn.microsoft.com/en-us/library/bb510680.aspx)
Yesterday I added some indexes on a view in my MSSQL 2008 db. After that it seems like all the store procedures need to run with QUOTED_IDENTIFIER set to ON, even those that don't use the view in question.
Why is it so? Is this something I can configure on the db or do I have to update all my stored procedures to set the QUOTED_IDENTIFIER to ON? I think it is rather weird that this is required for the stored procedures not using the view.
Do these stored procedures relate to the base table(s) that the view is based upon? To quote from Creating Indexed Views:
After the clustered index is created,
any connection that tries to modify
the base data for the view must also
have the same option settings required
to create the index. SQL Server
generates an error and rolls back any
INSERT, UPDATE, or DELETE statement
that will affect the result set of the
view if the connection executing the
statement does not have the correct
option settings. For more information,
see SET Options That Affect Results.
And it's kind of obvious, when you think about it - you're potentially going to be updating the contents of the view whenever you touch these base tables, and so you inherit the same responsibilities as when you created the index.
You can set the defaults at multiple levels:
Any application can explicitly override any default settings by executing a SET statement after it has connected to a server. The SET statement overrides all previous settings and can be used to turn options on and off dynamically as the application runs. The option settings are applicable only to the current connection session.
OLE DB and ODBC applications can specify the option settings that are in effect at connection time by specifying option settings in connection strings. The option settings are applicable only to the current connection session.
SET options specified for a SQL Server ODBC data source by using the ODBC application in Control Panel or the ODBC SQLConfigDataSource function.
Default settings for a database. You can specify these values by using ALTER DATABASE or the Object Explorer in SQL Server Management Studio.
Default settings for a server. You can specify these values by using either sp_configure or Object Explorer in SQL Server Management Studio to set the server configuration option named user options.
Ok, i know CONCAT_NULL_YIELDS_NULL will always be set to ON in future versions of SQL (insert MSDN search params(yadda,yadda)) so bear with me.
Boring details: The platform is MSSQL 2000 Enterprise (v8 sp4) AKA Critatious Period Edition.
The following will evaluate to NULL
SELECT 'abc' + NULL;
Understandable. But you can circumvent this with the following:
SET CONCAT_NULL_YIELDS_NULL OFF;
SELECT 'abc' + NULL;
In which case the result is "abc". From here on, future sql statements will allow concatenation with NULL. But is this a 'persistent' runtime setting? Such as, is this setting only applied for my session to the SQL server, or does it apply to statements executed by all users?
As far as i can tell, after setting _YIELDS_NULL to ON, a restart to the MSSQL services will have it default back to OFF (correct me if i'm wrong).
Last thing: I'm not actually planning to put this into practice. A third-party stored procedure failed (looks like they might have updated it, breaking it). Best i can figure is that they implemented it with the assumption that "SET CONCAT_NULL_YIELDS_NULL" was set to ON. And it used to always work.
I'm just looking for a cause: Is there a way to have CONCAT_NULL_YIELDS_NULL set to ON upon SQL server startup?
CONCAT_NULL_YIELDS_NULL can be set:
per connection - when you close connection and open new, it's back to default
per database
open Microsoft SQL Server Management Studio, rightclick your database and select properties. It's in the Miscellaneous section.
or from T-SQL
ALTER DATABASE database_name SET { CONCAT_NULL_YIELDS_NULL OFF }
Note: some clients can issue set concat_null_yields_null on command when opening connection. For example SQL Server Management Studio connecting to SQL 2005 does.
Use SQL Server Profiller to find about your connection.
I do not have SQL 2000 on my notebook to test exactly on that version.
As BOL goes,
If a SET statement is set in a stored
procedure, the value of the SET option
is restored after control is returned
from the stored procedure.
Therefore, the developer has very little to do to ensure correct settings. They could just set them in the beginning of the SP and didn't even have to restore original values afterwards.