Get the name of a columns default constraint on SQL Server 2000? - sql-server-2000

How do I get the name of a columns default contraint on a SQL Server 2000 installation? As far as I know sys.default_constraints is not available. Its different on every DB, the structure is like DF_table_column__3DE8FB0E for example.
Thanks :)

Try using INFORMATION_SCHEMA, SQL Server's implementation of the SQL 92 self-describing features.
SELECT * FROM INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE

Related

get schemas in a specific databse in ms sql server

I need to get the schemas list in specific database in MS SQL server, not all schemas list in entire MS SQL server
EX:
i will get list of Db's like A,B,C from ms sql server.Now i need to fetch all schema list from A
I need a query for that
can i get some help here
This can be accomplished using the sys.schemas catalog view:
USE A;
SELECT name
FROM sys.schemas;
3-part name example:
SELECT name
FROM A.sys.schemas;
You can obtain all schemas from specific database like this
USE Database_Name
SELECT * FROM sys.schemas
Read link below to have a better understanding
How do I obtain a list of all schemas in a Sql Server database

there a way to drop 'sysmessages' table from one database?

unfortunately i create table call 'sysmessages' in SQL Server 2008. when i restore the DB to SQL Server 2012 i realize that i have two Tables call 'sysmessages'.
i don't want to change my table name because it using in the code.
can i remove only from specific database system table?
it is not a table, but a view
of course you cannot remove it, but you don't need to. It is in a different schema. You will not address it like select * from sys.sysmessages, you will address it like select * from dbo.sysmessages
"i don't want to change my table name because it is used in the code" - you can/should change the code as well :)
edit - no. 2. is not applicable in SQL 2012, however it is tested and working in SQL 2008R2
You cant drop system tables,your best bet is to change your code

Utility to create sql statements

This is a question about Sql generation, not sql creating sql nor ORM.
Is their any cross database tools that will enable the creation of insert statements, e.g. for all the tables in particular schema or namespace. Say the namespace/schema is Aqua in Sql Server 2008, and your utility comes along and generates all possible insert statements for that namespace/schema. And it works on Oracle/MySql/Postgres/db2 etc.
Thanks.
Bob
ANSI SQL provides for a standard set of views under the schema INFORMATION_SCHEMA to provide metadata for just this purpose.
For generating simple table insert statement templates, all the information you really need to generate an insert statement for a given table is to execute this query:
select *
from INFORMATION_SCHEMA.COLUMNS
where TABLE_CATALOG = <my-db-name>
and TABLE_SCHEMA = <table-owner-schema>
and TABLE_NAME = <table-name>
order by ORDINAL_POSITION
in any database that supports the ANSI information schema views. That will give you one row for every column in the specified table, in the expected sequence.
Outside of the above, since no two vendors support the set of system tables with metadata, your pretty much SOL for a cross-database solution. And sadly, I don't believe the Oracle supports the ANSI information schema views.
Though you might look at Red Gate's product family: http://www.red-gate.com/

MySQL indexing compared to SQL Server

Does MySQL have a sysindexes table or am I just thinking of SQL Server? If not, is there an equivalent indexing feature within MySQL at all?
SYS tables are specifically SQL Server; the ANSI equivalent is INFORMATION_SCHEMA. Part of the reason SYS tables still exist on SQL Server is they sometimes include additional information not in the INFORMATION_SCHEMA tables...
On MySQL, you want to use INFORMATION_SCHEMA.STATISTICS:
SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE table_name = 'tbl_name'
AND table_schema = 'db_name'
InnoDB tables can definitely be indexed; not sure about the scope available with ISAM tables. The system information stuff is held in the information schema tables:
http://dev.mysql.com/doc/refman/5.0/en/schemata-table.html

"Invalid character value for cast specification" for linked 2008 SQL server in 2005 instance

I am attempting to create a linked server from a 2005 to 2008 Microsoft SQL Server. I do this regularly for 2005 instances, but this is the first step of my long journey into SQL 2008. I am able to create the linked server as any other linked server, I receive no errors, however any time I try to use the linked server for anything (a simple "SELECT *" statement, for example) I get this error in SSMS:
"OLE DB provider "SQLNCLI" for linked server {linked server name} returned message "Invalid character value for cast specification"."
What do I need to know about creating a linked server to a 2008 instance in a 2005 instance?
Turns out the tables I kept choosing to test, the most business important tables on the 2008 server, each had fields of the "geography" data type, which is new to 2008. When testing queries on one of the other tables without this datatype the query works correctly.
So...you know... it was...an "Invalid character value for cast specification" after all.
I suspect that this may be a collation issue.
Check that the collation is the same at the server, database and table levels.
To check the detault server collation run the following T-SQL:
exec sp_helpsort
To check the Databasea collation do the following:
SELECT DATABASEPROPERTYEX('DatabaseName', 'Collation') SQLCollation;
It's either collation (my first guess), or Unicode conversions (VARCHAR vs NVARCHAR). I'd upvote John, but I don't have enough reputation.
Was there a particular way that you were able to query the table on the linked server that had the geography fields and not get the error?
I have the same issue where I need to query a linked server and some of the tables have geography fields in them and even if I only select a text field I get the error. The only workaround that I can think of would be to split the geography fields off to new tables so that the queries to the tables don't break.