how call stored procedure when user click on report line?

have a way to add ability to report, to do somthing, like delete
record, by calling Stored procedure when user click on some line within
the report?Hey I feel reports should be meant for reporting/Viewing. You should not
provide something like delete or modify options from reports. Then it becomes
an entry screen. I hope you will agree on this point.
Amarnath
"mtczx232@.yahoo.com" wrote:
> have a way to add ability to report, to do somthing, like delete
> record, by calling Stored procedure when user click on some line within
> the report?
>|||mtczx232@.yahoo.com wrote:
> have a way to add ability to report, to do somthing, like delete
> record, by calling Stored procedure when user click on some line within
> the report?
RS can call a stored procedure, or any arbitrary SQL with a side-effect
such as deleting a record.
Your SQL should return a result set as well as deleting the record. You
could navigate to another report, passing a parameter containing the id
of the parameter to delete. This "deleting" report would display
instead of the main report, which could look a bit funny.
Alternatively you could navigate to a URL of an ASP or ASPX page that
does the job. Ideally you would set the target so the web page
displayed as a pop-up with a message like "record xx deleted" instead
of replacing the whole report.

How accurate is GetDate() ?

According to MS, GetLocalTime() (in C++) is only accurate to approx a
second,
even though it reports milliseconds, and calling it twice and computing
the
interval can on occasion lead to a negative interval.

Is T-SQL's GetDate() more accurate than that, or at least
non-decreasing?

Thanks,
JimOn 26 Sep 2006 11:28:07 -0700, jim_geissman@.countrywide.com wrote:

Quote:

Originally Posted by

>According to MS, GetLocalTime() (in C++) is only accurate to approx a
>second,
>even though it reports milliseconds, and calling it twice and computing
>the
>interval can on occasion lead to a negative interval.
>
>Is T-SQL's GetDate() more accurate than that, or at least
>non-decreasing?

Hi Jim,

Getdate() (or, to use the ANSI standard name, CURRENT_TIMESTAMP) is
accurate to 1/300th of a second. I've never seen it decrease. Apart from
that, it is as accurate as the system clock of the server - if an admin
sets the system clock three hours back, SQL Server will report from the
past.

--
Hugo Kornelis, SQL Server MVP|||Hugo Kornelis wrote:

Quote:

Originally Posted by

>
Getdate() (or, to use the ANSI standard name, CURRENT_TIMESTAMP) is
accurate to 1/300th of a second. I've never seen it decrease. Apart from
that, it is as accurate as the system clock of the server - if an admin
sets the system clock three hours back, SQL Server will report from the
past.
>

Just to split hairs over this a little: The maximum precision of the
value returned by GETDATE() is 1/300th of a second. That doesn't
necessarily mean it is *accurate* to within 1/300th of a second
compared to some other time measurement such as the system clock.
However, like Hugo, I have never heard of any issue where serial
executions of GETDATE() went negative. It's not difficult to verify
that the time returned by GETDATE() is within a fraction of a second of
the system clock value returned by other means.

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/...US,SQL.90).aspx
--|||>Is T-SQL's GetDate() more accurate than that, or at least non-decreasing? <<

Yes; read the other answers. The real answer is that the FIPS-127
tests require five or more decimal places of seconds in a timestamp for
Federal use. Maybe when we get to 64 bit hardware and a better
internal representation ..|||Thanks, fellows.

By way of experiment, I wrote a loop that wrote 100,001 GetDate()s to a
table,
with an identity column to record the sequence. That took ~2 sec on
this
server. Then I examined the 100,000 intervals. Their distribution:

Interval (sec) N
0 99855
..13 44
..16 100
..30 1

I conclude that on this particular SQL2000 server, the clock usually
ticks every
160 ms (but not always).

I did this a few times and never saw a negative interval, although
that's not proof
it could never happen.

Thanks again
Jim