Renaming All Default Contrainsts To Fit Into Naming Convention
Mar 14, 2008
I am currently trying to rename all of the Default constraints in my database to fit in with my naming convention of DF_+TableName+ColumnName. Since there are over 300 of the things, I don't particularly fancy doing them all manually.
--Set the table name
SET @tblname = (SELECT object_name(parent_obj) FROM sysobjects
LEFT JOIN sys.columns ON sys.columns.object_id = sysobjects.id
INNER JOIN sysconstraints ON sysobjects.id = sysconstraints.constid
WHERE sysobjects.xtype = 'D')
--Set the column name
SET @colname = (SELECT name FROM sys.columns
INNER JOIN sys.tables ON sys.tables.object_id = sys.columns.object_id
WHERE sys.tables.name = @tblname)
--Set the default constraint
SET @defname = (SELECT name FROM sysobjects JOIN sysconstraints
ON sysobjects.id = sysconstraints.constid
WHERE object_name(sysobjects.parent_obj) = @tblname
AND sysobjects.xtype = 'D'
AND sysconstraints.colid = (SELECT colid FROM syscolumns
WHERE id = object_id(@tblname) AND
name = @colname))
--Set the renaming
SET @cmd = EXEC sp_rename +@defname+, 'DF_'+@tblname+'_'+@colname+, 'OBJECT'
--Execute the renaming
EXEC(@cmd)
I know that the above is not correct in any way, but it is how far I have got before I got really stuck! And I thought it might help you see what I was trying to get at...
Hi all, I wanted to ask for the naming conventions in SQL SERVER.as in case of pl/sql server we have ..name_of_package.name_of_procedure thats how we call the procedures i.e. owner of schema then name of package n then procedure name.....i want to ask you all how is it done in SQL SERVER..please try to reply as soon as possible, i will b waiting for the replies, regards
I would lean towards the vigorous because it would be very obvious what data is being referenced by the name. In the loosened version, I could very easily have many tables with a 'id' column or a 'is_active' column.
Inversely, I would lean towards the loosened version because the names are a lot shorter and, thus, easier / faster to type.
I figure, if I'm going to learn a new standard, now's a good time to do so.
Is there any standard naming convention for SQL Server that microsoft suggest it? the same as naming guidlines in MSDN for designing libararies in .Net Framework.
I have an assignment to change names of the SPs that are not following Standard naming convention in all databases. For this first I need to find out all the SPs that are not following naming convention. Can anybody help me in finding out the objects that are not following standard naming conventions. It is first step in completing this assignment. If anybody deal with this type of task before please guide me. Hope any one of you will reply me with more information......
We have link-servers all over the place. The ideal naming convention should satisfy following:
- developers should not have to modify code when deploying between environments DEV->TEST->PROD. This rules out using actual server name as linked-name.
- the name should easily identify actual server without much mental translation. This rules out relevant but generic names like FAXSERVER or PAYSERVER
- also, if the name could state that it is a linked-server e.g starting with LINK_, it works when reading the code.
So, I was thinking the link-name should simply remove the environment :
e.g LINK_FAX_DB_V01
that way, on DEV box, the underlying sql data source could point to the dev server, while on test, it could point to test server etc. without having to change code, and also knowing which server it's pointing to by just adding a TST or PRD in front-of it.
I did a search (google and on the forums) and found a few suggestions here and there, but I'd like something more complete to follow as far as naming conventions are concerned.
I wrote my first DB based on MySQL/Ruby/Active Record type naming convention...
- plural table names - all lower cased - underscores between words - "id" is auto incrementer for each table - something+"_at" is for datetime fields - something+"_on" is for date fields - referencing the primary id in another table is "tablename (singular)" + "_id".
This worked great in Ruby/MySQL, but in C#/SQL Server, its an ambiguity nightmare! All of my "id" fields conflict and alot of my tables have "added_at" datetime fields and they all conflict with each other. Essentially, any field that's named the same in one table as in another conflict on joins.
For example: users post comments to stories submitted by users...
table = articles field 1 = id field 2 = title field 3 = body field 4 = user_id
table = comments field 1 = id field 2 = title field 3 = body field 4 = user_id field 5 = article_id
Trying to join these two tables is an ambiguity nightmare but I'd like to not have to name every field uniquely or start adding table prefixes to them all...
I guess I just need some good suggestions or links to recommended table structure/naming conventions for SQL Server. Thanks in advance!
Does anyone know how to tell sp_rename to look in a schema other than the default. The code below reproduces the problem.
-- WORKS IN default schema -- create table dbo.TestDF1( dfField intconstraint DF1 default 0 ) go
sp_rename 'DF1', 'DF2', 'OBJECT' go
Select name From sys.default_constraints where object_name(parent_object_id) = 'TestDF1' go
drop table dbo.TestDF1 go
-- DOESN'T WORK IN added schema -- create schema TestSchema go
create table TestSchema.TestDF2( dfField intconstraint DF3 default 0 ) go
sp_rename 'DF3', 'DF4', 'OBJECT' go
Msg 15248, Level 11, State 1, Procedure sp_rename, Line 315 Either the parameter @objname is ambiguous or the claimed @objtype (OBJECT) is wrong. --------------------------- drop table TestSchema.TestDF2 go
The Web Service Task seems to support calling methods using parameters but not (as far as I can see) using the Document/Literal calling convention. Is this correct? Is this likely to change in the future?
Just thought I'd point it out as something that needs fixing. This is inconsistent with every other MS product using the VS.net IDE framework.
I'd post it on Connect but then I'd wait 2 months to get "won't fix - this does not 'fit' with the current Katmai schedule" i.e. if I'm lucky (based on the new improved 3yr delivery of sql) it might get delivered in 2011. Wow.
Imagine if Xbox or PS3 designers told their customers, "sorry we know that up/down/left/right are in fact right/left/down/up, as you may expect on a game controller, but if you wait 3 years we might fix it"
Hello, I have 2 tables: Articles and Users. These 2 tables are related by AuthorId (FK) in Articles and UserId (PK) in Users. My question is: should the use the same name for the 2 keys, i.e., UserId? Or it is normal to use AuthorId in Articles table and UserId in Users table. This makes more sense. Just a naming question. Thanks, Miguel
What does everyone think of this method?I have a ton of tables like User, Project etc. I use the SAME column names for each table. For an example, ID, Name, Status etc instead of UserID etc.Only for relationship naming will I use UserID.The reason I do this is from a OOP perspective.My dad often said that a table was a entitiy of an object and each record in the table was a instance of that object.
I am using SQL Server 7 w/ SP2. This may seem silly, but I'm trying to re-name a DTS local package -- so far without success. Surely there's a way to do this. Also, where is DTS info stored? That is, how does SQL Server store package names and other details? Thanks!
Most of the programming I do is in Access. I like to use naming conventions for all my tables, queries, etc. I am now moving several databases to SQL Server. Does anyone know of a good resource for naming convetions in SQL Server. Website, book?
I'm creating a new database for an application that I wish to sell in the future. When we sell it the client will have the option to host is or have us host it. I want to create a name for the database that doesn't describe what the product is. I also want to be able to create new databases if we host it and those names be of a similar convention or subject. I was thinking each would be a Greek god, galaxy names or something along those lines. Does anyone have any suggestions?
I'm coming from a MS Access background and so I'm very used to andcomfortable with the hungarian (Leszynski et al) naming conventions.However, I'm getting started into my first SQL Server Database andreally want to use the appropriate up to date standard namingconvention (ISO compliant).I think I have the general idea from raking though countlessconflicting sites and posts, but I'm a bit stuck on what to doregarding pk / fk namingFor example, in my MS Access world I would have two tables:tblOrders=======strOrderIDintCustomerIDdtOrderDate....tblCustomers==========intCustomerIDstrCustomerName....So what would the appropriate and most up-to-date and standard namingbe for SQL Server? My Guess:Orders=====Ord_Order_ID_PkOrd_Customer_ID_FkOrd_Order_Date....Customers========Cus_Customer_ID_PkCus_Customer_Name....How close (or far) am I from "Celko Proof" naming here?All help gratefully accepted!
When I schedule a DTS package as a Job and then look in the job step detail I am presented with the following line.
DTSRun /~Z0x3A2210EB05CE1F9968C82E............etc
This number means nothing to me and I presume it might be encoded or encrypted. If I wanted to be sure that this code actually relates to the correct DTS package how can I check.
Is there a specific table that will hold that code that will relate it to the DTS package??
I use data driven subscriptiosn to deliver the same report to 6 different customers. But each customer can see only his data. Reports are saved in a shared folder in xl version. Reports are saved like report_1,report_2 etc. Is there anyother way to name these reports without letting customer to change the name?
We have two tables. Users and Projects and there is a many-to-many relationship.Ex. A user can be assigned into multiple projects.For the relationship table, should the table name be UserProjects or ProjectUsers?Also should it be singular or plural? (ex. UsersProjects or ProjectsUsers)?
I am trying to name a new SQL table, but I keep receiving a message that a table with this name already exists in the database. However, when I try to run a SELECT statement using that table, the error msg tells me the object does not exist,and it is not in the combobox of existing tables that can be added to a diagram.
Does anyone know if it is possible to create dynamically named tables from within a stored procedure? The goal is to append a unique identifier on the end of an otherwise static table name to allow for multiple incarnations of the table to exist concurrently while not interfering with each other. For example, we would like to create and use a temp table that is suffixed with a login name to or a timestamp to make it unique.
I was wondering if there are generally accpeted naming standards for SQL Server ojbects (tables, store procedeures, triggers, views etc.) that might be available somewhere on the WEB. I was also wondering if most DBA`s prefix the object names like "sp_" or suffix the object like "Customer_T"? Any opinions?
SQL Server 2005 cluster. Active-Active. We want to create two instances. The two nodes are named:
mike-940-01 mike-940-02
I read somewhere that there can only be ONE default instance in a 2005 cluster. So I interpret that as meaning that I can only have one instance named after a virtual server (example: mike-940-03) and the other instance has to be a slashed instance (example: mike-940-03/instance1). But what if I create another virtual server (example: mike-940-04). Can I install a default instance in that server? Can someone help me clarify this?
Also, if I'm using all slashed instance names, then what does it choose as the base name before the slash? In other words, what decides which virtual server name is used? Is it the management node? Is it one of the nodes?
My objective is to keep consistency in the naming on the cluster. If I have to use slashed instances, then I want all sql server instances to have a slash.
Sorry about the confusing explanation, but that's probably a symptom of MY confusion.