Predicate or key word all in uppercase?

Hi,

What is the dowside of not using all uppercase for predicates and key words?

I cannot find to see a problem beside adhering to a clean coding convention. After all I already have color coding so what would be the uppercase for?

Same question for the semicolon ; at the end of a sql block. Is that real necessary not to get in trouble sometime down the road or is it a non-issue. I find like I am now a C# guys if I use these ;

Just curious, I find tedious to switch from all upper case to normal case all the time. And not forget to type the ;

Thanks,

Philippe

Case doesn't matter for keywords. It is good to establish some consistent coding style in your organization though so it is easier to read the code. As for semi-colons, it will be good to use it in new code. There are also some new constructs that require use of semi-colon in previous statement to resolve ambiguities. And in a future version of SQL Server, we may require the use of semi-colons as statement separators.|||Thank you, got it.
About GO should I have "Some query" ; GO
or is Go Gone :-)
I never saw any advantage in using GO
it looks like it is implicit.
I suspect the answer is along the same line.|||GO is not a TSQL or SQL command. It is just a batch separator token for the client. You can configure it to be something else also if you want (like / or $$ etc).|||

Umachandar Jayachandran - MS wrote:

In a future version of SQL Server, we may require the use of semi-colons as statement separators .

Well, this seems frightening, I can't think of how many organizations would be in the impossibility to upgrade to such version without going through a major review of scores of existing (distributed) code. that seems very unlikely to happen. Lot of bugs ahead with that one.
I fully agree for brand new constructs but the day you can flip the switch to make this mandatory for every constructs seems very far away.
If it is 5 years from now, I am better off starting immediately in each piece of code I ever touch.
If it is 10 years from now, I can just start doing it for every new piece of code I create.
The legacy stuff should have vanished by then. At least for my application which has a somewhat short life cycle.
Philippe|||Our deprecation policy is fairly strict right now in the sense that we make announcement first in version N, then warning in version N + 1 and then deprecate in version N + 2. So you will have really multiple releases to transition and convert your code. Please take a look at the deprecation topics in say SQL Server 2000 and SQL Server 2005 for some examples on features that we announced for deprecation or removed and so on. Backward compatibility is a huge deal due to the installed application base for SQL Server and every release we go to great lengths to maintain that. The backward compat setting for databases are also a step towards that which allows you to run most code from previous version without changes. There are exceptions but those are considered breaking changes that you will have to fix in your application after/before upgrading. Lastly if you look at most of the examples in SQL Server 2005 Books Online or modules in Adventureworks db, you can see that the code uses statement terminators to suggest good coding practice.

Possible Primary Key Problem

I am struggling to get a relationship to work in my database and I cannot
get my head round the problem so I wondered if any of you knowledgeable
people on here knew the answer.
An image of my Diagram is here
(http://www.step-online.org.uk/relationship.png) showing some of the
relationships.
Everything works find as is.
I am now trying to create a many-to-many-to-many type of relationship (if
this is even possible).
My courses tables work fine as a many-to-many relationship.
I have created a new join table so I can link individuals to courses (using
the unique ID column in the Courses join table).
All the fields ending _ID are nnumeric data type with an identity set to
increment by 1 each time.
I have tried to create a relationship between XREF_Courses_ID in the
SYS_Xref_Join_Ind_Courses table and the same field (both primary keys) in
the SYS_Xref_Join_Courses table, and receive the following error:
"The columns in table 'SYS_Xref_Join_Courses' do not match an existing
primary key or UNIQUE constraint".
Why would this be?On Tue, 6 Apr 2004 12:22:53 +0100, "Keith" <@..> wrote:

>I am struggling to get a relationship to work in my database and I cannot
>get my head round the problem so I wondered if any of you knowledgeable
>people on here knew the answer.
>An image of my Diagram is here
>(http://www.step-online.org.uk/relationship.png) showing some of the
>relationships.
>Everything works find as is.
>I am now trying to create a many-to-many-to-many type of relationship (if
>this is even possible).
>My courses tables work fine as a many-to-many relationship.
>I have created a new join table so I can link individuals to courses (using
>the unique ID column in the Courses join table).
>All the fields ending _ID are nnumeric data type with an identity set to
>increment by 1 each time.
Aaarrgghhhhhh...

>I have tried to create a relationship between XREF_Courses_ID in the
>SYS_Xref_Join_Ind_Courses table and the same field (both primary keys) in
>the SYS_Xref_Join_Courses table, and receive the following error:
>"The columns in table 'SYS_Xref_Join_Courses' do not match an existing
>primary key or UNIQUE constraint".
>Why would this be?
>
Because the columns in that table do indeed not match an existing
primary key. Both tables hava a primary key over multiple columns, so
you can't use just one of these columns to create a relationship.
Explanation: any foreign key (which is what a relationship translates
to) needs to join on at least one side to a column or column
combination that identifies at most one row. Generally the primary
key; optionally a column combination with UNIQUE constraint (a
candidate key).
A many-to-many relationship can only be implemented through an extra
table. For the relationship between courses and individuals, something
like:
CREATE TABLE CourseSubscriptions
(IND_ID int not null,
COURSE_ID int not null,
PRIMARY KEY(IND_ID, COURSE_ID),
FOREIGN KEY(INT_ID)
references SYS_Individual(INT_ID),
FOREIGN KEY(COURSE_ID)
references SYS_Courses(COURSE_ID))
On second thoughts - it seems as if the Xref-Join-Ind-Courses (who
comes up with such names?) is already made for this purpose. Just get
rid of the superfluous XREF_Ind_Course_ID and create the one missing
foreign key constraint.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)