August 13, 2015 at 8:55 am
Brandie Tarvin (8/13/2015)
GilaMonster (8/13/2015)
Brandie Tarvin (8/13/2015)
GilaMonster (8/13/2015)
Sean Lange (8/13/2015)
Every table name and every column name are exactly 6 UPPER case letters.I'm working with one of those. Fortunately it's not case sensitive, but the tables are named as if they were.
Seriously, the limit for a table name is 128 characters iirc, why does the table have to be named TSKGRPMBRS?
Have you added the schema, the database, and the server name to that string to check the length? Maybe someone's thinking 4 dot notation means they have to keep the table names short because the schema / db / server names are so long?
Database name - 7 characters. Schema is dbo
Well there's no accounting for people who hate vowels.
They just figure you can't read it without the vowels so they have you confused.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 13, 2015 at 8:57 am
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.
August 13, 2015 at 9:00 am
SQLRNNR (8/13/2015)
Brandie Tarvin (8/13/2015)
GilaMonster (8/13/2015)
Brandie Tarvin (8/13/2015)
GilaMonster (8/13/2015)
Sean Lange (8/13/2015)
Every table name and every column name are exactly 6 UPPER case letters.I'm working with one of those. Fortunately it's not case sensitive, but the tables are named as if they were.
Seriously, the limit for a table name is 128 characters iirc, why does the table have to be named TSKGRPMBRS?
Have you added the schema, the database, and the server name to that string to check the length? Maybe someone's thinking 4 dot notation means they have to keep the table names short because the schema / db / server names are so long?
Database name - 7 characters. Schema is dbo
Well there's no accounting for people who hate vowels.
They just figure you can't read it without the vowels so they have you confused.
There's accounting for people who hate vowels, it's just different than the rest of the accounting profession. 😉
Consider without vowels that: Debit - Credit = Dbt - Crdt
August 13, 2015 at 9:04 am
Ed Wagner (8/13/2015)
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.
Having been working in case sensitive environments, I learned to write that way. I want my code to be able to work in both case sensitive and case insensitive environments without having to make any changes.
If a table is called MYTABLE, that's how I write it in my queries. If it is called MyTable, same thing. I hate seeing code where people use MyCol, MYCOL, mycol interchangeably because it happens to work because the system is using a case insensitive collation.
August 13, 2015 at 9:08 am
Crystal Ball, report to Aisle 5
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
August 13, 2015 at 9:08 am
Heh, things like that with names always make me shake my head. I recently ran across a database that had table in the dbo schema that also had 'dbo.' as the beginning of the table name. A tad annoying, but the same instance also has a database with 90,000 tables, so I really should expect such things 🙂
August 13, 2015 at 9:10 am
GilaMonster (8/13/2015)
Seriously, the limit for a table name is 128 characters iirc, why does the table have to be named TSKGRPMBRS?
Because consonants are free and vowels cost $250. 😛
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
August 13, 2015 at 9:13 am
Ed Wagner (8/13/2015)
Sean Lange (8/13/2015)
Every table name and every column name are exactly 6 UPPER case letters.I feel your pain. Baan's tables were named using a multi-part naming convention that made it a bit silly to try and remember. Example:
t$ttdsls040400
t$ttdsls041400
t$ = Prefix necessary for all tables and columns.
t = Prefix that does nothing except add another "t" to the table name.
td = Package the table is a part of. TD, logically, means Triton Distribution.
sls = Module the table is a part of. SLS means Sales.
040 = Which table it is. Naturally, 040 is Sales Orders and 041 is Sales Orders Lines. Not Sales Order Lines, but Sales Orders Lines.
400 = The company number. You can have multiple companies set up in one database, each with their own set of tables. The company number is the suffix for everything.
The columns where not quite as bad, but almost:
t$orno
t$pono
t$txta
t$txtb
t$ = Prefix necessary for all tables and columns.
next 4 = Field name. Clearly, orno = Order Number, pono = Position Number, txta = pointer to the text table for the this text entry. Note I didn't say foreign key, because where were none.
The text table was: t$tttxt001400.
Obviously, the package "tt" is Triton Text, the module "txt" is Text and the table was 001. There was no 002.
And yes, the whole thing was case sensitive in both object names and values.
See why it gave me nightmares?
I know what you mean. All the columns in a table have a 2 character prefix. These prefixes have no meaning as it relates to the table. So you end up with names like PHTXID and PHSCCD.
It is kind of scary I am starting to actually be able to identify some of the more common columns. I know that a column with the last 4 of RGDT is the integer version of the date the row was created. And RGTM is the integer version of the time the row was created. This creates some really interesting words to be echoed through the dev team as something as simple as getting rows created since yesterday require lots of effort to convert those integers into something you can convert to a datetime so it is actually usable.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
August 13, 2015 at 9:16 am
Lynn Pettis (8/13/2015)
Ed Wagner (8/13/2015)
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.Having been working in case sensitive environments, I learned to write that way. I want my code to be able to work in both case sensitive and case insensitive environments without having to make any changes.
If a table is called MYTABLE, that's how I write it in my queries. If it is called MyTable, same thing. I hate seeing code where people use MyCol, MYCOL, mycol interchangeably because it happens to work because the system is using a case insensitive collation.
I agree. I tend to make my code use the same case as defined in the table. However I hate when I see things like this.
create table #temp
(
MYCOL int
, MyCol int
, mycol int
)
That to me is the greatest shortcoming of a case sensitive collation. That just shouldn't work. In a case insensitive collation this is invalid.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
August 13, 2015 at 9:19 am
Jacob Wilkins (8/13/2015)
Heh, things like that with names always make me shake my head. I recently ran across a database that had table in the dbo schema that also had 'dbo.' as the beginning of the table name. A tad annoying, but the same instance also has a database with 90,000 tables, so I really should expect such things 🙂
IIRC it was common on SQL 2000 when trying to assign schema names to tables via database diagram.
😎
August 13, 2015 at 9:19 am
Lynn Pettis (8/13/2015)
Ed Wagner (8/13/2015)
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.Having been working in case sensitive environments, I learned to write that way. I want my code to be able to work in both case sensitive and case insensitive environments without having to make any changes.
If a table is called MYTABLE, that's how I write it in my queries. If it is called MyTable, same thing. I hate seeing code where people use MyCol, MYCOL, mycol interchangeably because it happens to work because the system is using a case insensitive collation.
Not to be too marketing focused, but, I have a solution [/url]for the case sensitive issue... Just sayin'.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 13, 2015 at 9:21 am
Sean Lange (8/13/2015)
Lynn Pettis (8/13/2015)
Ed Wagner (8/13/2015)
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.Having been working in case sensitive environments, I learned to write that way. I want my code to be able to work in both case sensitive and case insensitive environments without having to make any changes.
If a table is called MYTABLE, that's how I write it in my queries. If it is called MyTable, same thing. I hate seeing code where people use MyCol, MYCOL, mycol interchangeably because it happens to work because the system is using a case insensitive collation.
I agree. I tend to make my code use the same case as defined in the table. However I hate when I see things like this.
create table #temp
(
MYCOL int
, MyCol int
, mycol int
)
That to me is the greatest shortcoming of a case sensitive collation. That just shouldn't work. In a case insensitive collation this is invalid.
That would make a good interview question. Under what conditions is this statement valid?
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
August 13, 2015 at 9:21 am
WayneS (8/13/2015)
Crystal Ball, report to Aisle 5
I'm sure that a large part of this is English as a second language. But lordy, can the questions be worded more vaguely?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 13, 2015 at 9:22 am
Grant Fritchey (8/13/2015)
Lynn Pettis (8/13/2015)
Ed Wagner (8/13/2015)
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.Having been working in case sensitive environments, I learned to write that way. I want my code to be able to work in both case sensitive and case insensitive environments without having to make any changes.
If a table is called MYTABLE, that's how I write it in my queries. If it is called MyTable, same thing. I hate seeing code where people use MyCol, MYCOL, mycol interchangeably because it happens to work because the system is using a case insensitive collation.
Not to be too marketing focused, but, I have a solution [/url]for the case sensitive issue... Just sayin'.
Yeah that makes it a lot easier for case-sensitivity.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 13, 2015 at 9:24 am
Grant Fritchey (8/13/2015)
Lynn Pettis (8/13/2015)
Ed Wagner (8/13/2015)
I've worked in both environments and really prefer case-insensitive. As a habit, though, I try to write everything as case-sensitive.Having been working in case sensitive environments, I learned to write that way. I want my code to be able to work in both case sensitive and case insensitive environments without having to make any changes.
If a table is called MYTABLE, that's how I write it in my queries. If it is called MyTable, same thing. I hate seeing code where people use MyCol, MYCOL, mycol interchangeably because it happens to work because the system is using a case insensitive collation.
Not to be too marketing focused, but, I have a solution [/url]for the case sensitive issue... Just sayin'.
PLUG PLUG PLUG~~~~~~~~\0/~~~~~/\~~~~~~
😎
Viewing 15 posts - 50,161 through 50,175 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply