Changing the source wth a button

Hi,

I have this Gridview in which I show attendees to a course (per course)

In the same gridview I want to be able (by clicking a button) to show all attendees to all courses simply by leaving out a part of the SQL;

WHERE Eventid = @.eventid (resulting in all attendees no matter what course)

In other words how can I alter the selectcommand of the SQLDataSource?

Seems simple, but can't hack it.

Thanks in advance,

Lx

Hello my friend,

There are several ways to do this. A straightforward one would be to reserve a number to mean ALL of them, like so: -

SELECT * FROM MyTable WHERE (EventID = @.EventID OR @.EventID = -1)

Now just pass in -1 when you want to get all of them.

Kind regards

Scotty

|||

Hi,

Thank you,

The actual SQL is not a problem. I want to change the Selectcommand using a Commandbutton.

Lets say.

Clicking Button 1 results in the use of the Selectcommand: SELECT * FROM MyTable (resulting in all attendees no matter what course)

Clicking Button 2 results in the use of the Selectcommand: SELECT * FROM MyTableWHERE Eventid = @.eventid

Thanks in advance,

Lx

|||

Hi,

Turned out to be quite simple:

<Grid>.SelectCommand =

"SELECT Blahblah" in the code for the Button worked fine.

Lx

changing fieldsize in a replicated database

I am looking for a way to increase the size of a varchar field in a
replicated database, without disturbing the data of course. I do not
want to remove the replication just for this one issue. What would the
process be in writing a SQL query to accomplish this? The table name is
tblBid, and the field is bidNotes. It is a varchar(500), and I would
like it to be 900. Is there a size limitation on varchars?
Thanks.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Daniel,
Directly this can't be done. Indirectly it can, but not nicely! You could
add a new column with the new datatype (sp_repladdcolumn), do an update on
the table to populate the column, then drop the column (sp_repldropcolumn).
Do this again to create the column having the same original name.
BTW this is available directly using Alter Table in SQL 2005.
Rgds,
Paul Ibison (SQL Server MVP)
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Changing Explain Plan

Hi,
We have a stored proc that generally returns in about 4-5 seconds. Over the
course of a few days (2-5) the stored proc starts returning in about 50 sec
onds. The change is sudden, not a gradual degradation. The explain plan ha
s changed. If I then add a
hint to the main query (loop join), compile it, take the hint back out, comp
ile it (ie it is now exactly the same as it was), it then starts returning i
n 4-5 seconds once again.
We have automatic creation and update of statisics turned on. The profile o
f the data doesn't change that much day-to-day.
Why is it so? How to stop SQL Server from changing the plans for this query
?
TIA,
SJTHi SJT,
Sudden performance degrade might might be due to "Fragmetation". Can you
execute the DBCC SHOWCONTIG on all tables and identify the tables
which is fragmented. For all fragmented table you could run DBCC DBREINDEX
or DBCC INDEXDEFRAG to remove fragmetation.
See the details of DBCC SHOWCONTIG, DBCC DBREINDEX and DBCC INDEXDEFRAG in
boks online.
How to stop SQL Server from changing the plans for this query?
See "Execution Plan Caching and Reuse" in books online.
Thanks
Hari
MCDBA
"SJT" <SJT@.discussions.microsoft.com> wrote in message
news:E48CD7B7-28C0-4A13-99C7-5ED85FB7E5D8@.microsoft.com...
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over
the course of a few days (2-5) the stored proc starts returning in about 50
seconds. The change is sudden, not a gradual degradation. The explain plan
has changed. If I then add a hint to the main query (loop join), compile
it, take the hint back out, compile it (ie it is now exactly the same as it
was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this
query?
> TIA,
> SJT|||SJT,
instead of rewriting the query two times, see if "sp_recompile <name of
SP>" achieves the same thing.
Also, search Google for "parameter sniffing", and see if that is causing
your procedure's peformance fluctuation.
Hope this helps,
Gert-Jan
SJT wrote:
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over the cours
e of a few days (2-5) the stored proc starts returning in about 50 seconds. The cha
nge is sudden, not a gradual degradation. The explain plan has changed. If I then
add
a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it
is now exactly the same as it was), it then starts returning in 4-5 seconds once again.[vbco
l=seagreen]
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this que
ry?
> TIA,
> SJT[/vbcol]
(Please reply only to the newsgroup)

Changing Explain Plan

Hi,
We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add a
hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
Why is it so? How to stop SQL Server from changing the plans for this query?
TIA,
SJT
Hi SJT,
Sudden performance degrade might might be due to "Fragmetation". Can you
execute the DBCC SHOWCONTIG on all tables and identify the tables
which is fragmented. For all fragmented table you could run DBCC DBREINDEX
or DBCC INDEXDEFRAG to remove fragmetation.
See the details of DBCC SHOWCONTIG, DBCC DBREINDEX and DBCC INDEXDEFRAG in
boks online.
How to stop SQL Server from changing the plans for this query?
See "Execution Plan Caching and Reuse" in books online.
Thanks
Hari
MCDBA
"SJT" <SJT@.discussions.microsoft.com> wrote in message
news:E48CD7B7-28C0-4A13-99C7-5ED85FB7E5D8@.microsoft.com...
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over
the course of a few days (2-5) the stored proc starts returning in about 50
seconds. The change is sudden, not a gradual degradation. The explain plan
has changed. If I then add a hint to the main query (loop join), compile
it, take the hint back out, compile it (ie it is now exactly the same as it
was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this
query?
> TIA,
> SJT
|||SJT,
instead of rewriting the query two times, see if "sp_recompile <name of
SP>" achieves the same thing.
Also, search Google for "parameter sniffing", and see if that is causing
your procedure's peformance fluctuation.
Hope this helps,
Gert-Jan
SJT wrote:
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add
a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this query?
> TIA,
> SJT
(Please reply only to the newsgroup)

Changing Explain Plan

Hi,
We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
Why is it so? How to stop SQL Server from changing the plans for this query?
TIA,
SJTHi SJT,
Sudden performance degrade might might be due to "Fragmetation". Can you
execute the DBCC SHOWCONTIG on all tables and identify the tables
which is fragmented. For all fragmented table you could run DBCC DBREINDEX
or DBCC INDEXDEFRAG to remove fragmetation.
See the details of DBCC SHOWCONTIG, DBCC DBREINDEX and DBCC INDEXDEFRAG in
boks online.
How to stop SQL Server from changing the plans for this query?
See "Execution Plan Caching and Reuse" in books online.
Thanks
Hari
MCDBA
"SJT" <SJT@.discussions.microsoft.com> wrote in message
news:E48CD7B7-28C0-4A13-99C7-5ED85FB7E5D8@.microsoft.com...
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over
the course of a few days (2-5) the stored proc starts returning in about 50
seconds. The change is sudden, not a gradual degradation. The explain plan
has changed. If I then add a hint to the main query (loop join), compile
it, take the hint back out, compile it (ie it is now exactly the same as it
was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this
query?
> TIA,
> SJT|||SJT,
instead of rewriting the query two times, see if "sp_recompile <name of
SP>" achieves the same thing.
Also, search Google for "parameter sniffing", and see if that is causing
your procedure's peformance fluctuation.
Hope this helps,
Gert-Jan
SJT wrote:
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this query?
> TIA,
> SJT
--
(Please reply only to the newsgroup)