I don't know how to phrase this question, but I'm trying to do this:
alter table [TEMP]
add SEQID int identity(1,1)
This works; however, what I really need is a float column instead of an int:
alter table [TEMP]
add SEQID **FLOAT** identity(1,1)
I think this is illegal. Please let me know if it is not.
Is there a work around to getting a float ID column?
Edit: Is there a way to create the identity column as int, then remove the identity attribute, and then convert the column to a float?
You can do what you want as:
create table temp (
id int identity(1,1),
fid as cast(id as float)
)
This adds the id as an integer but then has another column that is computed by converting it to float.
Why are you creating new ids for a legacy system?
Or, you can add the computed column to an existing table:
alter table temp add fid as cast(id as float)
I don't know if I understand why you want a floating point ID. That column is usually just stored as an int (bigint, smallint, depends on the table...) but an int will uniquely identify each row of the table sufficiently to allow you to query each of them without data contamination. You just have to make sure to Join the tables correctly.
If you're really sure about using float, then I think this would suffice, unless I'm missing something:
alter table [TEMP]
add SEQID float identity(1,1)
Related
I have a table in SQL server that accepts either a true or false value. Is there anyway to say that it can be true or false and not a fixed value. My table is for a container that can hold hot food or cold food. I want some of the containers to be able to carry hot or cold food depending on an order.
SQL Server has Bit type. Try Something like this:
CREATE TABLE yourtablename
(
ID int PRIMARY KEY,
IsHot bit not null default 1
)
Did you try check constraint?
Example code:
CREATE TABLE dbo.Vendors
(VendorID int PRIMARY KEY, VendorName nvarchar (50),
CreditRating tinyint)
GO
ALTER TABLE dbo.Vendors ADD CONSTRAINT CK_Vendor_CreditRating
CHECK (CreditRating >= 1 AND CreditRating <= 5)
This this example we're forcing column CreditRating to store values from 1 to 5. Hope this helps.
I want to create a table with computed column for its custom ID column. The format which I want is BID(The Year)-0000 for example the one like this:
BID2017-0001
I tried the below t-sql code but I get the non-deterministic error. How can I solve this problem?
CREATE TABLE Books
(ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
BookID AS 'BID'+CAST(YEAR(GETDATE()) as VARCHAR(4))+ RIGHT ('0000' + CAST(ID AS VARCHAR(4)), 4) PERSISTED UNIQUE,
ISBN VARCHAR(32),
BookName NVARCHAR(50),
AuthorName NVARCHAR(50),
BLanguage VARCHAR(50),
StaId int,
StuId int,
CatNo int);
I tried this article too but couldn't solve the issue.
non-deterministic
UPDATE
Furthermore, I need the series of '0000' to be reset back to '0000' when the new year starts. For example, The last ID in 2017 is 'BID2017-0932' when the year is changed to 2018 I would like zero series in the ID to be reset to '0000' for example 'BID2018-0001' how can I achieve this ??
Simplest solution
I would add a CreateDate column thus:
ALTER TABLE dbo.Books
ADD CreateDate DATETIME NOT NULL
CONSTRAINT DF_Books_CreateDate
DEFAULT(GETDATE())
GO
then I would add computed column thus:
ALTER TABLE dbo.Books
ADD BookID AS ('BID' + LTRIM(YEAR(CreateDate)) + '-' + RIGHT('0000' + LTRIM(ID), 4)) /*PERSISTED*/
GO
you have getdate() in your code which makes the column non deterministic.Removing that will help ..
If you want to know why getdate() is nondeterministic.check here:Is GetDate() deterministic..
Excerpt from answer
deterministic means that the function returns the same value given the same inputs. In this case you have no inputs, but you get different values all the time! The system clock is not an input, it is external state that the function relies upon.
I have created a table and set its PK to IDENTITY(1,1).
But I want the PK to begin/start with alphabets e.g CRMSON0, CRMSON1, CRMSON2... and so on.
But I wasn't able to find the solution for Microsoft SQL Server.
on Microsoft website, details I could find were about IDENTITY(seed,increment) or IDENTITY(data type,seed,increment).
Can anyone suggest?
You can create computed column composed from CRMSON + ID value:
CREATE TABLE #table1 (ID INT IDENTITY(0,1)
,col INT
,col_pk AS CONCAT('CRMSON', ID) PRIMARY KEY);
INSERT INTO #table1(col) VALUES(3), (4);
SELECT *
FROM #table1;
LiveDemo
The best solution is to use
an ID INT IDENTITY(1,1) column to get SQL Server to handle the automatic increment of your numeric value
a computed, persisted column to convert that numeric value to the value you need
So try this:
CREATE TABLE dbo.YourTable
(ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
CrimsonID AS 'CRIMSON' + CAST(ID AS VARCHAR(10) PERSISTED,
.... your other columns here....
)
Now, every time you insert a row into YourTable without specifying values for ID or CrimsonID:
INSERT INTO dbo.YourTable(Col1, Col2, ..., ColN)
VALUES (Val1, Val2, ....., ValN)
then SQL Server will automatically and safely increase your ID value, and CrimsonID will contain values like Crimson1, Crimson2,...... and so on - automatically, safely, reliably, no duplicates.
That'll work fine - but as others have already pointed out - I would NOT recommend using this column as the clustered, primary key - use the ID column for that, it's ideally suited for such a task! The CrimsonID is bad for mainly two reasons: it's a variable length string, and it's much too wide compared to an int
Lets say I have a CREATE TABLE code like this:
CREATE TABLE Test (
ID int NOT NULL IDENTITY(1,1),
SortIndex int,
Name nvarchar(50) NOT NULL
);
I was wondering if it's possible to make a table in MSSQL which had the ability to insert the ID's value into the SortIndex column when I run an INSERT.
So I would run this INSERT:
INSERT INTO Test (Name) VALUES ('Awesome Dude');
Which would normally yield the row:
ID,SortIndex,Name
1,NULL,"Awesome Dude"
But I'd like it to automatically be:
ID,SortIndex,Name
1,1,"Awesome Dude"
Is this even possible by altering the CREATE TABLE script, or do I have to use a TRIGGER?
I would be inclided to take a slightly different approach to this. If you want your SortIndex to default to the ID, but be overridable, I would use a nullable column, and a computed column:
CREATE TABLE Test (
ID int NOT NULL IDENTITY(1,1),
OverrideSortIndex int,
Name nvarchar(50) NOT NULL,
SortIndex AS ISNULL(OverrideSortIndex, ID)
);
If you need to change the sort index for any reason, update the column OverrideSortIndex and this takes precedence.
I have a table with some columns
CREATE TABLE test (
testid INT,
field1 CHAR(10),
field2 VARCHAR(50),
field3 DATETIME,
field4 MEDIUMINT
[...]
);
Now I want to be able to have a setting in my app that will allow me to to either enable or disable some of those for particular users.
CREATE TABLE user (
userid INT
);
I was thinking about:
CREATE TABLE user_test_visible (
userid INT,
field1 BOOL,
field2 BOOL,
field3 BOOL,
field4 BOOL
[...]
);
Also I was thinking about something like this :
CREATE TABLE user_test_visible (
userid INT,
field_name VARCHAR(30),
visible BOOL);
Are any of those approaches sensible?
I would suggest do something like this maybe.
CREATE TABLE test
(
fieldId INT,
field CHAR(10)
)
To have one table that contains the fields. Then if you need to add one more (change of requirements) you do not have to add a new column.
The I would skip the boolean and go with one table that has a shared primary key. Like this:
CREATE TABLE user_test_visible (
userid INT,
fieldId INT
);
The reason why I would suggest skipping the boolean is that if there is no row do show the field. That depends on what your start value is. If you want the users to see all field from the begining then you might consider having the table like this:
CREATE TABLE user_test_not_visible (
userid INT,
fieldId INT
);
Then where there is a row in this table then do not show the filed.
Edit
When use insert the field you must have some pre deployment script right? There you can also specify which columns that are visible and which is not. If you have different data types then ether have the layout like you have or you can just a sql_variant. But beaver that this type of column is not supported in for example linq-to-sql as a primary key.
That is just my idés. Hope it helps
Perhaps a more flexible approach would be to define "roles" within your application. A user would be associated with one or more roles, and each role would be associated with a set of columns. The union of those column sets would be what a user can see. This approach will require more effort to work out what columns a user can see, but it would make user management easier in the long term. It also separates user privileges from what that means in terms of database access.