When creating a new Primary Key field, for a SQL server database in Visual Studios. I noticed that they type of the field can be uniqueidentifier. This can also be changed to nvarchar and int or bit. I also noticed though in the attributes of the field I can specify 'TRUE' for isRowGUID.
When Visual Studios creates an XSD definition automatically after importing the database (an .SDF file for this particular instance. AKA SQL compact) It automatically maps the type uniqueidentifier to the CLR type GUID. What advantages, if any, does setting the isRowGUID to true provide?
Any information or direction in this question is appreciated, as all previous efforts to gather infromation on this subject have yielded little to nothing.
Basically, rowguidcol/isrowguidcol tells SQL Server that the column is a unique row identifier much like identity does for an int column (uniqueness is enforced). It also forces a default value on the column much like identity sets the seed and increment values on an int column. Just like there can be only one identity column for a table, there can be only one rowguidcol per table.
Rowguidcol enables you to refer to, access and/or identify this column using system stored procedures. Also, SQL Server Replication can/will use the uniqueidentifier column marked as rowguidcol/isrowguidcol if available. If not, replication will add the uniqueidentifier/rowguidcol to your existing table. If you are planning on using SQL Server Replication, it might be advisable to add the column yourself as part of the design so at last you can name the column something useful.
Check out this link from Microsoft for more info ... http://msdn.microsoft.com/en-us/library/ms191131(v=sql.105).aspx
Related
I am trying to set the default value for a new column I just added. In properties I am trying to set 'Default Value or Binding' to a simple XML along the lines of:
<root>
<title>Welcome</title>
<body>Thank you for your time.</body>
</root>
However, when I click away, I get an error:
SQL error validating the default for column
I set this value in other numerical columns and it worked fine. What gives?
Not sure, but the visual designers in SQL Server Management Studio often don't quite work properly...
Just use a simple T-SQL statement to achieve the same thing:
ALTER TABLE dbo.YourTableName
ADD CONSTRAINT DF_YourTable_YourXmlColumn
DEFAULT '<root><title>Welcome</title><body>Thank you for your time.</body></root>'
FOR YourXmlColumn
and you're done!
(You didn't specify your table and column names - so I just made up placeholders - do replace those with your actual table and column names! Also: for the default constraint, I'd always recommend specifying an explicit name - makes it easier to disable and/or drop the constraint later, if you ever need to; my default naming convention is shown - again: adapt to your needs / likes)
It is true that knowing what TSQL command to run is advantageous in many ways but just to add an answer for SQL Server Management Studio so it is not swept under "it doesn't quite work properly", the syntax is ('[xml here]').
('<root><title>Welcome</title><body>Thank you for your time.</body></root>')
I have a column named Lastmodified, with a data type of Date, but it should have been DateTime.
Is there any way of converting the column?
When I use the 'Design' feature of SQL Server Management Studio I get the following error:
Saving changes is not permitted. The changes you have made require the following
table to be dropped and re-created.
Not really interested in dropping the table, I just want to know if it is possible to convert a column from Date to Datetime or do I have to delete the column and create a new one with the correct data type?
It shouldn't need to drop the table and recreate it, unless that column is taking part in one or more constraints.
You can just do it using SQL:
ALTER TABLE Tab ALTER COLUMN LastModified datetime2 not null
(I chose datetime2 over datetime, since the former is recommended for all new development work, and since the column is currently date, I know you're on SQL Server 2008 or later)
That's just a safety setting in SQL Server Mgmt Studio - you can turn it off, if you're adventurous :-)
Disable the checkbox there and you can do whatever you like!
You can't change the type of a column in place. You need to create a new column, copy of the values over, and then drop the original column.
SQL Management Studio usually accomplishes this by creating a temporary table with the new column name, copying the values over, dropping the original table with the old column, and then renaming the new temporary table to the new name. Often it does this without people even realizing it.
However, this can be a very invasive approach, especially if you already have a lot of rows in the table, so you may want to just write a SQL script add the new column to the table, copy the values over, drop the original column, and then use sp_rename to change the new temporary column name back to the original column name. This is the same idea as what SQL Management Studio is doing, except they are dropping and recreating the whole table, and you are just dropping and recreating the column.
However, if you DO want to let SQL Manangement Studio do it this way, you can turn off that error message. I believe it was originally added because people did not wantdrop and recreate the table by default. To turn this message off, go to Tools->Options-?Designers, and uncheck the "Prevent saving changes that require table re-creation", then you should be able to save your changes in the designer.
I'm using SQL Server 2008 R2 and I can't seem to be able to use the geography column type it's meant to have. It doesn't show up in the data type column when I create a new column and when I run this code:
CREATE TABLE [Core].[Address2](
[Geo_Id] [geography] NULL);
I get
Column, parameter, or variable #2: Cannot find data type geography.
Am I doing something wrong or do I need to enable the new data types somehow?
At the risk of stating the obvious, I'd double check to make sure the database you're using is indeed on a SQL 2008 instance.
I have found that when you add a geography column you need to restart the Management Studio in order for it to appear in intellisense. This might be the issue you are having perhaps?
I'm trying to add a simple configuration to a SSIS package, of type SQL Server, so stored in a table. At the end of the wizard, when it goes to try and write a new row to the nominated table to store the configuration it fails with the error:
TITLE: Microsoft Visual Studio
Could not complete wizard actions.
Cannot retrieve configuration table schema. (Microsoft.DataTransformationServices.Wizards)
I can't seem to resolve this. The configuration connection has full permissions on the table, and it sees it and can read from it as it reports there is no current data for the filter I provide. It just wont write to it. A Google search of the error message above in quotes returns literally no hits! Any suggestions?
Glenn
Turned out to be a mismatch between the table structure that existed on my machine and the table structure that is used by a SQL Server Configuration. Ensuring the table matched the default SSIS Config schema below fixed the error.
[ConfigurationFilter] nvarchar NOT NULL,
[PackagePath] nvarchar NOT NULL,
[ConfiguredValueType] nvarchar NOT NULL,
[ConfiguredValue] nvarchar null
If anyone needs it, you have to verify if the packagePath column in your table has the correct string value, and it must match with the property that you want to configure.
Does anyone have an idea what this error means or how to solve it? I am using Access 2003 and SQL2005. It comes up when trying to add a record on a particular subform.
[Microsoft][SQL Native Client] Invalid character value for cast specification (#0)
This MS bug report describes the same message, but it is a bug in SQL Server 6.5 that has already been solved.
Solved: Apparently having no PK on the destination table was causing this, it didn't have anything to do with the subform or the query from Access. I wasn't even aware there were tables in this database without PK. Adding PK to the destination table solved it. The strange thing is the same query string that errored when executed via SQL native client, executed through SSMS with no errors. Hope this helps anyone else who has come across that strange message.
Hum, I would check the text box default on the access side. I would also bring up the linked table in design mode, and you want to check the data type that ms-access assumes here. For non supported data types ms-access will generally use a string, and sql server might be wanting something else.
So, check both the Primary key (PK) in main table, and then check the data type used (assumed) in the child table for the foreign key (FK) column. While we are at this, check your expressions used for the child/master link settings in the sub-form control (not the form, not the sub-form, but the sub-form control used in your form that links up these two tables).
Sub forms in access are sensitive if you don’t have a timestamp column in the sql server table. As mentioned check the PK and the FK data types and make sure they match up (just bring up the tables in design mode in ms-access -- you get an error message about the design mode being read only, but just continue on so you can check/view to ensure the data types match up).
So for the child table, you need a PK, a FK, and also a timestamp column (you don’t have to display the TS column in the sub-form, but you need it in the table).
Sub-forms in ms-access are sensitive and often fail if you don’t include a timestamp column in the sql table. (access uses these row version columns to determine if the data been changed).
Is one of your fields in the view calculated/built with the CAST function? In this case, you might not have the right to update/add a value for that field.
Can you execute your view in the MS SQL Studio interface and try to insert a record?
Another cause to this issue is that if you change a table name without alterting the view then the "Dependencies" of that view still remians with the table old name.
Let say I have a table 'A' and a view 'Av' which derives from 'A', and I created a new Table which will be named 'A' and I changed 'A's name to 'A_old' but I didn't executed an ALTER VIEW, so the dependencies of 'Av' still remain on 'A_old' but the view is derives from 'A' and it cuasing this Error in Access when trying to open the view as a linked table
I just spent a day battling this with an Access ADP project that was imported into a new Access 2016 ACCDB file. Initially I figured it was an issue with the application code, but I was getting this keying records directly into the table. Interestingly, the records always got written - it seemed to be the read-back that was triggering the error. Profiling the insert sql and running that from SQL Management Studio worked without any issues.
The table that was causing the problems had a GUID Primary Key. Switching that to an int column resolved the issue.
The SQL database was also littered with a few thousand extended properties which I removed before switching the PK. There was a strong suggestion from the web that these cause problems. The source of that process is documented here: Remove All SQL Extended Properties
I had this problem with Access 2016 trying to update an ODBC linked sQL Server database. Problem was a null value in field used to join the two tables. Eliminating the null value solved the problem
OK I just had this bad experience and it had nothing to do with PK or any of this stuff in my situation. The view that reported this problem in Access was created in SQL Server originally and used a CAST of DATETIME to plain old DATE to get rid of the unneeded time part. Up until today this view had caused 0 issues in Access, but started to generate heartburn just as described above.
So, I generated a Drop/Create script for the MSS view, ran it, relinked the views in Access, and the Access database was happy with the result. All my so-called tables in Access are basically views through links to MSS for reporting. I only have 1 table that actually does changes. Other than that, I do not edit through views in Access.
The message is of course useless as usual but this was my solution in my situation.
Based solely in the message you provided above, it appears that you are trying to set an invalid value to some field or parameter, etc... The message is telling you that it is trying to convert a value into an specific data type but the value is invalid for that data type... makes sense?
Please add more details so we can help you better.