November 19, 2012 at 11:51 am
CELKO (11/19/2012)
...
Oh, IDENTITY cannot be a valid key for table either.
...
Sorry to disappointing you again, but it really can!
Have you tried it? If you need our help we can show how it does work...
Just in case:
IDENTITY
Indicates that the new column is an identity column. When a new row is added to the table, the Database Engine provides a unique, incremental value for the column. Identity columns are typically used with PRIMARY KEY constraints to serve as the unique row identifier for the table.
from
November 19, 2012 at 12:24 pm
It seems that CELKO missed his meds again.
The way to educate people is not to berate them. You could bring so much knowledge and understanding to the community if you would attempt to help people learn instead of belittling their intelligence. Try posting an alternative to their solution instead of just insulting their approach and telling them how horrible their approach is. I know I would love to see your approach to this type of problem.
_______________________________________________________________
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/
November 20, 2012 at 1:32 am
CELKO (11/19/2012)
Actually #Table2 has the date, but as its only to the minute, there are duplicates - and the order of TEXT2 does not help - see the last few lines of the sample data - and my added column RowNum has duplicates.
Duplicates? then it is not a table by defintion because it cannot have a key. Oh, IDENTITY cannot be a valid key for table either. But it sure makes you magetnic tape file programmers feel better since it lets you find physical insertion order.
I had assumed (incorrectly as it turns out) that this problem would have a standard SQL solution as its a classic two file problem read file A, go down file B looking for a match. Save position in file B, read next from A, continue down file B from saved position. I've done this kind of thing in procedural languages many times.
EXACTLY! Your mindset is still stuck writing sequential mag tape code in a set-oriented declarative world. A read/write head position, local variables to hold changing data, etc. You are the flat earth kid in a Geography class :-D!
You need to get a book on RDBMS and read before you try to program again. What you got here is a pile of stinking kludges that only trap you into that old mindset.
Why don't you take a day or two and try to do this with set-oriented programming
and post it? The DDL should have keys, constraints, Declarative Referential Integrity, and good data types. If you know how, follow ISO-11179 data element naming conventions and formatting rules. Temporal data should use ISO-8601 formats. Code should be in Standard SQL as much as possible and not local dialect.
Thank you for your assessment ...
Now go back and hide under your bridge.
November 20, 2012 at 3:50 am
t.brown 89142 (11/20/2012)
CELKO (11/19/2012)
...
...
Common J.Celco rant
...
Thank you for your assessment ...
Now go back and hide under your bridge.
@t.browm
Here I may disappoint you, he must be rich enough to live on his own private island, somewhere in Austin. Although, he might have some bridges there...:hehe:
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply