I have read the following article. They have quoted that,
SQL Server is a case-sensitive back-end application. This means that a
table named "addr" is distinguished from a table named "ADDR."
However, because Microsoft Query is an MS-DOS-based application, it is
unable to distinguish cases; therefore, Microsoft Query views "addr"
and "ADDR" as the same file.
Now I wanted to know what to they mean by case-sensitive back-end application? Is it safe to use the query with case-insensitivity?
Thanks in advance.
SQL Server with default collation will return you the same result, doesn't matter which case you use for your query.
Collation can be set at various levels
Server
Database
Column
For more info can be found out here
Please check Applies To section of the article you referenced. KB article applies to product from Microsoft for which they no longer provide any support.
Related
I am creating indexes on two separate tables in the same Database (MS SQL Server), and I got an error saying that an index already exists.
This error does NOT come up again if I changed index name to another.
Please help. Many Thanks.
Screenshot from Microsoft SQL Server Management Studio
I'd strongly suggest that the visual designer is leading you astray. IIRC, indexes used to have schema-scoped names (back in the 7.0 or 2000 era, I think. Before user/schema separation) and later gained the ability to only need to be unique at an individual table level1.
If you try to create a duplicate index manually, you receive the error:
The operation failed because an index or statistics with name '<name>' already exists on table '<table name>'.
Since that's clearly not the error you're seeing, I strongly suspect that it's old code in the visual designer and yet another reason not to use it.
1Unfortunately, we're in an area where historic documentation from the right period is no longer available from the Microsoft website. It used to be easier to verify these recollections because you could still find the "What's new in SQL Server 2000", etc pages there.
Hi i am using SQL Server 2012. i would like to view the system objects code/definition. can we view the system objects definition/code in SQL Server any version ?
wanted to know when i execute this query SELECT MONTH(18/200), MONTH(200/18) i am getting output 1 for both just want to know internal code what is going on and how it is giving output 1 for MONTH(200/18) ? to understand this looking for MONTH() function code.
Use INFORMATION_SCHEMA
An information schema view is one of several methods SQL Server
provides for obtaining metadata.
Information schema views provide an
internal, system table-independent view of the SQL Server metadata.
Information schema views enable applications to work correctly
although significant changes have been made to the underlying system
tables.
The information schema views included in SQL Server comply
with the ISO standard definition for the INFORMATION_SCHEMA.
answer to SELECT MONTH(18/200), MONTH(200/18) is any integer to the MONTH() interprets 0 as January 1, 1900. that's whey it is returning 1 1 as output.
The company I work for uses a bunch of different SQL servers and I was wondering how to select a different SQL server in the same script.
For example, I want to select data from a table on a database in server 1 and using that data to get data from another table on a database in server 2. I tried googling the solution but I couldn't find anything relevant to my problem.
Thanks in advance.
You can set them up as linked servers.
http://msdn.microsoft.com/en-us/library/aa560998(v=bts.10).aspx
then you syntax will be
SERVERALIAS.DBNAME.owner.TABLE
Use fully qualified names (i.e. select * from [server].[database].[owner].[tablename])
Also, be sure to setup those servers as linked servers. There are several articles online how to do this.
I agree with Kyle & Flavio that You have to use four part naming convention to whatever server,database,table & column data like this:
Select * from [Servername].[Databasename].[Owner].[Tablename]
A cleaner option is to set up Synonyms to your linked servers. This way, you alias the server, and therefore don't have to hard code the 4 parts into every query.
If you hard code and later change a server's name, you will have to hunt down every reference and update. With Synonyms, all you'll have to do is update the applicable Synonym.
Synonyms give you transparent external tables, procedures, and UDFs.
MSDN here.
Assume SQL Server 2005+.
Part A:
What is the canonical way to query from the system/internal/meta/whatever tables/views (sorry, not a database ninja) for any user table or column names that use SQL Server keywords (like case)?
I don't mind maintaining the list of keywords if that's not query-able, as it only changes with versions of SQL Server supported (right?).
Looking at available views in SQL Server 2005, I can easily enough query this information from INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.TABLES, but I want to be sure it's from the best possible location for future-proofing.
Part B:
Is it possible to get the list of keywords via query?
UPDATE: While a useful concept, I'm specifically not interested in escaping the column/table/etc names in question because I'm hoping to write a tool that will check for tables/columns/etc that share names with keywords and provide useful warnings to developers. The tool would be used during code reviews at my office to point out that the developer might want to consider renaming the entity. (Or hopefully by the developer before code reviews for their own good!) I may even set it up for use with continuous integration in my build scripts, but that's only a thought for the future.
You should properly quote the names used. If you generate code, use the built-in QUOTENAME function. Don't build a list of known keywords, instead quote every name used for every object, including database name, schema name and object name. Also make sure you always adhere to the correct case of the objects involved. As a best practice, develop on a case sensitive collation server instance. Developing code on case insensitive server collation (default) can lead to embarasing failures on production when deployed on case sensitive collation servers.
For Part A
Personally I would go for sys.columns and sys.objects actually. INFORMATION_SCHEMA views are also good, and they're 'portable' in theory, I'm just so much more used to the SQL specific ones though. I choose sys.objects vs. sys.tables because it covers more (eg. views). I would suggest you also cover table valued functions, table valued parameter types (in 2008 only) and temporary #tables and table #variables declared inside stored procedures. That would leave out only temp #tables and table #variables declared in batches sent by clients, but those are basically in client code only.
A: Just use brackets around your identifier.
select [procedure].[case] from [procedure]
B: I'm not sure if you can query for them, but there is a MSDN page about it.
If you need these programmatically, I suggest you insert them all into a table for your own uses.
Why do you need to know the list of keywords? a: they don't change very often, and b: for any regular code (I'm excluding things like "sql server management studio") you can just use square brackets:
SELECT [table].[column], [table].[join]
FROM [table]
I have the displeasure of generating table creation scripts for Microsoft Access. I have not yet found any documentation describing what the syntax is for the various types. I have found the documentation for the Create Table statement in Access but there is little mention of the types that can be used. For example:
CREATE TABLE Foo (MyIdField *FIELDTYPE*)
Where FIELDTYPE is one of...? Through trial and error I've found a few like INTEGER, BYTE, TEXT, SINGLE but I would really like to find a page that documents all to make sure I'm using the right ones.
I've found the table in the link below pretty useful:
http://allenbrowne.com/ser-49.html
It lists what Access's Gui calls each data type, the DDL name, DAO name and ADO name (they are all different...).
Some of the best documentation from Microsoft on the topic of SQL Data Definition Language (SQL DDL) for ACE/Jet can be found here:
Intermediate Microsoft Jet SQL for Access 2000
Of particular interest are the synonyms, which are important for writing portable SQL code.
One thing to note is that the Jet 4.0 version of the SQL DDL syntax requires the interface to be in ANSI-92 Query Mode; the article refers to ADO because ADO always uses ANSI-92 Query Mode. The default option for the MS Access interface is ANSI-89 Query Mode, however from Access2003 onwards the UI can be put into ANSI-92 Query Mode. All versions of DAO use ANSI-89 Query Mode. I'm not sure whether SQL DDL syntax was extended for ACE for Access2007.
For more details about query modes, see
About ANSI SQL query mode (MDB)
This has it all. It's direct from MS, and actually tells you what the SQL datatype is that correlates to the GUI name.