Record , Row number

Hi
How can i have Row number in my SELECT Statement ?

Thanks

Let's get back to the basics of an RDBMS. Rows are not records; fields
are not columns; tables are not files; there is no sequential access or
ordering in an RDBMS, so "first", "next" and "last" are totally
meaningless. If you want an ordering, then you need to havs a column
that defines that ordering.  You must use an ORDER BY clause on a
cursor -- the keys have nothing whatsoever to do with the display in
the front end.

You have missed the WHOLE POINT of RDBMS.  Please stop writing code
until you know what you are doing.

--CELKO--  wrote:
> Let's get back to the basics of an RDBMS. Rows are not records; fields
> are not columns; tables are not files; there is no sequential access or
> ordering in an RDBMS, so "first", "next" and "last" are totally
> meaningless. If you want an ordering, then you need to havs a column
> that defines that ordering.  You must use an ORDER BY clause on a
> cursor -- the keys have nothing whatsoever to do with the display in
> the front end.
>
> You have missed the WHOLE POINT of RDBMS.  Please stop writing code
> until you know what you are doing.
>

Manager: I'm concerned about one of the figures on this report
Deputy: Which one?
Manager: 4th column.
Deputy: Which line?
Manager: Hang on while I count down from the top.
Deputy: Hope you don't mis-count then.
Manager: Aye, you don't wanna be chasing up the wrong thing
Deputy: Can't we just put line numbers on these reports like the old
system had?
Manager: No, Celko said we must go back to the basics of an RDBMS
Deputy: Ah, so you could identify the line to me without counting, just
tell me what's unique about it.
Manager: I could, if I knew WTF was unique about it, you should know us
management types have absolutely no technical knowledge.
Deputy: So these management reports were written for....
Manager: Aye, technical people to read.

If Elham gets his answer, his managers will have more time to play with
their newton's cradles.

LOL

Sometimes seemingly silly requests have perfectly sensible reasons
behind them, and sometimes the reason is even stupider than the
request.  Our purpose is not to question why, but rather to do as we
are asked and to take the blame like men.

-- Mark D Powell --

LOL!

One of the other basic concepts is that you do reports in the front end
and not in the database.   There are days I miss green bar paper.

>One of the other basic concepts is that you do reports in the front end
>and not in the database

which in many cases is very inefficient to put it mildly. Front ends do
change way more frequently than back ends. Several front ends may
connect to one and the same back end. For instance, if I have
- Java beans
- COM objects
- Crystal Reports
- C++ modules running on Linux
- ASP.Net Web pages

accessing one and the same database, why should anyone redo one and the
same simple tedious work line numbering lines 5 times?
Any decent database developer can do it just once, and easily.
If Crystal Reports are phased out and replaced by something else, the
database developers' work will still be in place, ready to be utilized
by whatever else comes into play next

--CELKO-- wrote:

> There are days I miss green bar paper.

I miss Mr. Angry who used to fly around the building like an Andrex
puppy and shouting about someone printed an object file instead of a
source file. You can take his place Joe :-)

>>  Front ends do change way more frequently than back ends. Several front e
nds may
connect to one and the same back end. <<

Which is why you do the reporting and formatting in the front end and
keep the back end as simple, standard  and clean as possible.  The last
thing you want is a query set up for report X1 on product Y1 and a
logically equivalent query set up for report X2 on product Y2 with
different formatting.   Remember the goal of databases and tiered
architectures -- remove redundancy!