September 14, 2006 at 8:22 pm
Concure with that... isn't there an autonumbering column or a date/time column or a consecutive ID column of any sort? How about a clustered primary key? There has to be something in the table to ensure the order using an ORDER BY or clustered key in order to do this.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:18 pm
No, that table must be imported from some hierarchical database.
So, you cannot find any key in table itself, you must know how and where this particular system holds the order of records in its tables.
_____________
Code for TallyGenerator
September 14, 2006 at 10:14 pm
Off the beaten path a bit, Serqiy, but what happened to your number of posts? You were way up there and now you have less than 1000? What'd they do? Reset you? This the same "Serqiy" I've known for so long, isn't it?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 10:51 pm
Yes, Sergiy here is still the same for at least 3 years.
Actually I don't look on my number of posts, only on others.
So I cannot tell you what happned to my number and if something actually happened.
But does it really matters? Tell me, I'll change my attitude to those numbers.
_____________
Code for TallyGenerator
September 15, 2006 at 6:42 am
Nope... it doesn't matter if they're 2 or 20,000... especially when someone posts as well as you do Dunno... maybe I need some stronger coffee
--Jeff Moden
Change is inevitable... Change for the better is not.
September 15, 2006 at 7:44 am
If you need to work with a table that already holds such values, you are in problems. You can try to calculate something, but you have no guarantee that it will work correctly. SQLS does not store rows in any special order, and if you issue the same SELECT (without ORDER BY clause) several times, you can get the rows in different order each time... yes, quite often you will get the same subset if you use SELECT TOP 10 without ORDER BY repeatedly - but "often" is not good enough, right?
If you are just preparing for the moment when you'll be moving the data from one system to another (or if you can delete all data from the unfortunate table and import it again), make sure you assign unique numbers to rows before you ever insert them into SQLS tables... even better, parse the arriving data into header and lines and use identification of respective header (20001, 20002....) in each created orderline.
Good luck!
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply