Code error please help

my code was working fine but i changed a few things and now i cant figure it out.

the problem is that when i click my edit button none of the items go into the listbox. i added a label to track th error and i narrowed it done to a smaller ssection. Please help

//------------------------ /////////////////////////////////////////////////////////////////////////////////protected void EditButton1_Click(object sender, EventArgs e) {int counter = 0;//counter for inserting into arraybool Validate = checknumberValidation(TextBox1.Text.ToString());if (Validate ==false)throw new Exception(InvalidCheckNumber + TextBox1.Text); Label4.Text = GridView1.Rows.Count.ToString();//---RETURNS 0--SHOULD BE NUMBER OF ITEMS--// //get # of checkboxes and set array size;int x = 0; x = SetStringArraySize();//set x to number of checkboxes that are checked String[] updateString =new String[x];//create string array of size x Label4.Text = GridView1.Rows.Count.ToString();//---RETURNS 0--SHOULD BE NUMBER OF ITEMS--// //for loop that will insert update statements into arrayfor (int i = 0; i < GridView1.Rows.Count; i++) { GridViewRow row = GridView1.Rows[i];bool isChecked = ((CheckBox)row.FindControl("UpdateCheckBox1")).Checked;if (isChecked ==true) {if (counter == 0) updateString[counter] ="[batchid] = '" + GridView1.Rows[i].Cells[3].Text +"' AND [loanid] = '" + GridView1.Rows[i].Cells[5].Text +"' AND [historycounter]='" + GridView1.Rows[i].Cells[8].Text +"'";if (counter > 0) updateString[counter] ="[batchid] = '" + GridView1.Rows[i].Cells[3].Text +"' AND [loanid] = '" + GridView1.Rows[i].Cells[5].Text +"' AND [historycounter]='" + GridView1.Rows[i].Cells[8].Text +"'"; counter++; } }//Add items to listbox and set listbox to visible. Panel1.Visible =true; PanelGridView.Visible =false; Panel2.Visible =false; updateCount.Text = updateString.Length.ToString(); updateCheckNumber.Text = TextBox1.Text;int q = 0;while (q < updateString.Length) { ListBox1.Items.Add(updateString[q]); q++; }//Label1.Text = temp.Length.ToString(); //Test print to label }//------------------------ //COMPLETEprotected int SetStringArraySize() { Label4.Text = GridView1.Rows.Count.ToString();//---RETURNS 0--SHOULD BE NUMBER OF ITEMS--//int count = 0;for (int i = 0; i < GridView1.Rows.Count; i++) { GridViewRow row = GridView1.Rows[i];bool isChecked = ((CheckBox)row.FindControl("UpdateCheckBox1")).Checked;if (isChecked ==true) { count++; } } Label4.Text = GridView1.Rows.Count.ToString();//---RETURNS 0--SHOULD BE NUMBER OF ITEMS--//return count;//returns number of checkboxes that are checked }///////////////////////////////////////////////////////////////////////////////// //------------------------

Are you saying GridView1 has no rows at time of clicking button? Have you checked it's Databound? Try adding a Gridview1.DataBind() statement before accessing the Rows.Count property.|||

ill give that a try.

I added a e.rowsaffected on the pageload for a count and it returns the correct number in the gridview on the page load. Then when i click my edit button it still says the number of rows but the other label still says 0. Ill try what you said, hopefully that works

|||

ok the label now returns the correct count but i have narrowed down the problem to my function that checks for the check boxes.

protected int SetStringArraySize() { Label4.Text = GridView1.Rows.Count.ToString();int count = 0;for (int i = 0; i < GridView1.Rows.Count; i++) { GridViewRow row = GridView1.Rows[i];bool isChecked = ((CheckBox)row.FindControl("UpdateCheckBox1")).Checked;if (isChecked ==true) { count++; } }return count;//returns number of checkboxes that are checked }

This always returns 0. my guess is it is not finding the control "UpdateCheckBox1" so here is the html code to go with it where i specify the check box and it shows up and is functional.

<%@. Page Language="C#" MasterPageFile="~/MasterPage2.master" AutoEventWireup="true" CodeFile="checknum.aspx.cs" Inherits="checknum" Title="Intranet - Utilities - Check Number Assignment" %><%@. Register Assembly="eWorld.UI, Version=2.0.0.2148, Culture=neutral, PublicKeyToken=24d65337282035f2" Namespace="eWorld.UI" TagPrefix="ew" %><asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="Server"><!-- Auto Refresh page after 16 Minutes (1000 seconds) <meta http-equiv="refresh" content="1000"; url="checknum.aspx" />--> <script type="text/javascript" language="javascript"> function SelectAllCheckboxes(spanChk) { // Added as ASPX uses SPAN for checkbox var oItem = spanChk.children; var theBox=(spanChk.type=="checkbox")?spanChk:spanChk.children.item[0]; xState=theBox.checked; elm=theBox.form.elements; for(i=0;i<elm.length;i++) { if(elm[i].type=="checkbox" && elm[i].id!=theBox.id) { //elm[i].click(); if(elm[i].checked!=xState) elm[i].click(); //elm[i].checked=xState; } } }//end function function fnCheckTextBox1(sender, args) { var TextBox1 = document.getElementById("SearchTextBox1"); var TextBox2 = document.getElementById("SearchTextBox2"); if (TextBox1.value == '') { TextBox2.value = ''; TextBox2.disabled = true } else { TextBox2.disabled = false; } args.IsValid = true; } div><table style="width: 100%; font-size: 11pt"><tr style="width: 100%"><td style="width: 100%; text-align: center; background-color:#5D7B9D"> <strong><span style="color: white">Check Number Assignment</span></strong></td></tr></table></div> <div> <table style="font-size: 10pt; width: 100%"> <tr> <td align="right" style="width: 118px" valign="middle"> <span style="font-size: 10pt">PayeeID:</span></td> <td style="width: 20%" valign="middle"> <ew:MaskedTextBox ID="SearchTextBox1" runat="server" Font-Size="10pt"> </ew:MaskedTextBox></td> <td style="width: 20%" valign="bottom"> <asp:Button ID="SearchButton1" runat="server" Font-Size="10pt" Text="Search" OnClick="SearchButton1_Click" /> <asp:Button ID="resetButton" runat="server" Font-Size="10pt" OnClick="resetButton_Click" Text="Reset" /></td> <td rowspan="3" style="width: 48%"> <span style="font-size: 9pt">When searching by PayeeID use % as a wildcard. <br /> Example to search for all payees that have 'abc' in their PayeeID you would type %abc%<br /> <br /> Enter TransactionDate as mmddyy<br /> <br /> <asp:Label ID="Label2" runat="server" Text="Label" ForeColor="#FF0000"></asp:Label> <br /> <asp:Label ID="Label3" runat="server" ForeColor="#FF0000"></asp:Label> <br /> <asp:Label ID="itemCount" runat="server" Text="Label" ForeColor="Green"></asp:Label></span></td> </tr> <tr> <td align="right" style="width: 118px; height: 32px;" valign="middle"> <span style="font-size: 10pt">BatchID:</span></td> <td style="width: 20%; height: 32px;" valign="middle"> <ew:MaskedTextBox ID="SearchTextBox2" runat="server" Font-Size="10pt"> </ew:MaskedTextBox></td> <td style="width: 20%; height: 32px;"> </td> </tr> <tr> <td align="right" style="width: 118px; height: 34px;" valign="middle"> <span style="font-size: 10pt">TransactionDate:</span></td> <td style="width: 20%; height: 34px;" valign="middle"> <ew:MaskedTextBox ID="searchTransDate" Mask="99/99/99" ValidationExpression="^\d{2}/\d{2}/\d{2}$" runat="server"></ew:MaskedTextBox></td> <td style="width: 20%; height: 34px; text-align: center;"> <asp:Label ID="Label4" runat="server" Text="Label"></asp:Label></td> </tr> </table> <asp:Panel ID="Panel3" runat="server" Height="52px" Visible="False" Width="100%"> <hr style="height: 1px" />  <br /> <asp:Label ID="Label1" runat="server" Text="Label" Font-Size="10pt"></asp:Label><br /> <span style="font-size: 10pt"><strong>To change more check #s please click reset!<br /> </strong></span> </asp:Panel> <asp:Panel ID="Panel1" runat="server" Height="50px" Visible="False" Width="100%"> <span style="font-size: 10pt">You are about to change the check number on the following <asp:Label ID="updateCount" runat="server" Text="Label"></asp:Label> items to Check# <asp:Label ID="updateCheckNumber" runat="server" Text="Label"></asp:Label>.<br /> </span> <asp:Button ID="updateConfirm" runat="server" Font-Size="10pt" OnClick="updateConfirm_Click" Text="Confirm" />       <asp:Button ID="updateCancel" runat="server" Font-Size="10pt" OnClick="updateCancel_Click" Text="Cancel" /><br /> <br /> <br /> <asp:ListBox ID="ListBox1" runat="server" Font-Size="8pt" Height="172px" Width="100%"> </asp:ListBox></asp:Panel> <br /> <asp:Panel ID="Panel2" runat="server" Height="34px" Width="100%"> <asp:Button ID="EditButton1" runat="server" Text="Update" Width="72px" OnClick="EditButton1_Click" Font-Size="10pt" Height="24px" /> <span style="font-size: 10pt">Check #: <asp:TextBox ID="TextBox1" runat="server" Width="160px" Font-Size="10pt"></asp:TextBox></span></asp:Panel> <asp:Panel ID="PanelGridView" runat="server" Height="500px" ScrollBars="Auto" Width="100%"> <br /> <asp:GridView ID="GridView1" runat="server" AllowSorting="True" AutoGenerateColumns="False" CellPadding="4" DataSourceID="SqlDataSource1" ForeColor="#333333" GridLines="None" Font-Names="Verdana" Font-Size="10pt" PageSize="20" EnableViewState="False"> <FooterStyle BackColor="#5D7B9D" Font-Bold="True" ForeColor="White" /> <Columns> <asp:TemplateField> <ItemTemplate> <asp:CheckBox ID="Update_CheckBox1" runat="server" /> </ItemTemplate> <HeaderTemplate> <input id="Update_CheckBox1" onclick="javascript:SelectAllCheckboxes(this);" runat="server" type="checkbox" /> </HeaderTemplate> </asp:TemplateField> <asp:BoundField DataField="TransactionDate" HeaderText="Posting Date" SortExpression="TransactionDate" DataFormatString="{0:MM/dd/yyyy}" HtmlEncode="False" ReadOnly="True" /> <asp:BoundField DataField="CheckNumber" HeaderText="Check #" SortExpression="CheckNumber" ReadOnly="True"> <ItemStyle HorizontalAlign="Center" /> </asp:BoundField> <asp:BoundField DataField="BatchID" HeaderText="BatchID" SortExpression="BatchID" ReadOnly="True" /> <asp:BoundField DataField="PayeeID" HeaderText="PayeeID" SortExpression="PayeeID" ReadOnly="True" /> <asp:BoundField DataField="LoanID" HeaderText="LoanID" SortExpression="LoanID" ReadOnly="True" /> <asp:BoundField DataField="TransactionAmt" HeaderText="Transaction Amount" SortExpression="TransactionAmt" ReadOnly="True" DataFormatString="{0:f2}" HtmlEncode="False"> <ItemStyle HorizontalAlign="Right" /> </asp:BoundField> <asp:BoundField DataField="FeeDesc" HeaderText="Fee Description" SortExpression="FeeDesc" ReadOnly="True" /> <asp:BoundField DataField="HistoryCounter" HeaderText=" " SortExpression="HistoryCounter" ReadOnly="True"> <ItemStyle CssClass="hiddencol" /> </asp:BoundField> </Columns> <RowStyle BackColor="#F7F6F3" ForeColor="#333333" /> <EditRowStyle BackColor="#999999" /> <SelectedRowStyle BackColor="#E2DED6" Font-Bold="True" ForeColor="#333333" /> <PagerStyle BackColor="#284775" ForeColor="White" HorizontalAlign="Center" /> <HeaderStyle BackColor="#5D7B9D" Font-Bold="True" ForeColor="White" /> <AlternatingRowStyle BackColor="White" ForeColor="#284775" /> </asp:GridView> <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="

|||

<asp:TemplateField>
<ItemTemplate>
<asp:CheckBox ID="Update_CheckBox1" runat="server" />
</ItemTemplate>
<HeaderTemplate>
<input id="Update_CheckBox1" onclick="javascript:SelectAllCheckboxes(this);" runat="server"
type="checkbox" />
</HeaderTemplate>
</asp:TemplateField>
==========================================================

is actually correct below. I just tried changing the name to see if that was it.

==========================================================

<asp:TemplateField>
<ItemTemplate>
<asp:CheckBox ID="UpdateCheckBox1" runat="server" />
</ItemTemplate>
<HeaderTemplate>
<input id="UpdateCheckBox1" onclick="javascript:SelectAllCheckboxes(this);" runat="server"
type="checkbox" />
</HeaderTemplate>
</asp:TemplateField>
==========================================================

Clustered Index

We are currently addressing many performance issues in an existing
application. One of the items we are investigating is adding clustered
indexes to tables that do not have them. Currently, about 90 tables out of
200 don't have clustered indexes. The long-term solution is to analyze each
table and determine what the best clustered index is. As a shorter-term
solution I've done some analysis to determine what some of the best
candidates would be by writing a query to analyze primary keys, identity
columns, and unique indexes. The problem is that many of these tables have
none of those (primary keys, identity columns, or unique indexes).
With the understanding that this database has much to be redesigned (meaning
I'm not currently looking for comments on bad design), this is my question:
What are the benefits / divantages of adding an IDENTITY column and a
CLUSTERED INDEX on that identity column to every table that does not have a
clustered index, primary key, identity column, and unique index. I'm mainly
looking for insight into any divantages or problems this will cause. The
reason for the identity column is that it would be a "safe" column to add
from an application perspective and would be a decent candidate for the
clustered index.
I'm very hesitant about doing this blindly and am sing to find out if its
feasible in the short-term to gain performance by eliminating heaps in this
manner without introducing other problems.
Thanks,
Mike Jansen> What are the benefits / divantages of adding an IDENTITY column and a
> CLUSTERED INDEX on that identity column to every table that does not have
> a clustered index, primary key, identity column, and unique index.
Why do your tables not have keys?
If the column is not there for any good reason, I see no advantage in adding
it. But I really am curious why you have enough tables without the above
elements where this is even a concern or some desperate grasp at using a
jackhammer to hang a picture...|||> What are the benefits / divantages of adding an IDENTITY column and a
> CLUSTERED INDEX on that identity column to every table that does not have
a
> clustered index, primary key, identity column, and unique index. I'm main
ly
> looking for insight into any divantages or problems this will cause. T
he
> reason for the identity column is that it would be a "safe" column to add
> from an application perspective and would be a decent candidate for the
> clustered index.
The only benefit will be that using an identity column will avoid page split
during insert operations, but from the point of view of query performance,
only you can know. You should analyze every posible query you execute agains
t
the table and from there, spot possible columns. Preferable those used in
range queries, "group by" and "sort by" operations.
Tips on Optimizing SQL Server Clustered Indexes
http://www.sql-server-performance.c...red_indexes.asp
AMB
"Mike Jansen" wrote:

> We are currently addressing many performance issues in an existing
> application. One of the items we are investigating is adding clustered
> indexes to tables that do not have them. Currently, about 90 tables out o
f
> 200 don't have clustered indexes. The long-term solution is to analyze ea
ch
> table and determine what the best clustered index is. As a shorter-term
> solution I've done some analysis to determine what some of the best
> candidates would be by writing a query to analyze primary keys, identity
> columns, and unique indexes. The problem is that many of these tables hav
e
> none of those (primary keys, identity columns, or unique indexes).
> With the understanding that this database has much to be redesigned (meani
ng
> I'm not currently looking for comments on bad design), this is my question
:
> What are the benefits / divantages of adding an IDENTITY column and a
> CLUSTERED INDEX on that identity column to every table that does not have
a
> clustered index, primary key, identity column, and unique index. I'm main
ly
> looking for insight into any divantages or problems this will cause. T
he
> reason for the identity column is that it would be a "safe" column to add
> from an application perspective and would be a decent candidate for the
> clustered index.
> I'm very hesitant about doing this blindly and am sing to find out if i
ts
> feasible in the short-term to gain performance by eliminating heaps in thi
s
> manner without introducing other problems.
> Thanks,
> Mike Jansen
>
>|||> Why do your tables not have keys?
You would have to ask people who left before I started.

> If the column is not there for any good reason, I see no advantage in
> adding it. But I really am curious why you have enough tables without the
> above elements where this is even a concern or some desperate grasp at
> using a jackhammer to hang a picture...
Adding the identity column has no other purpose other than to create a
decent candidate for a clustered index (because its an always-increasing
value and won't be changed) where time is lacking to determine a better one.
The idea I'm trying to get valid feedback on is: Generally speaking, does
adding an identity column and a clustered index on that identity column give
me a performance gain over a heap without introducing any significant
problems? And if it does introduce problems, what might they be? The
assumption being just having a clustered index on a table will perform
better on SELECTs than SELECTs on a heap. Adding the identity column and
clustering on it is to avoid performance problems during INSERTs or UPDATEs
from a poorly chosen clustering index without having to do the full analysis
of all 50 tables. I realize that better analysis will yield a better
clustering index. So I'm not looking for comments on that. I'm looking for
input on whether this will truly be better performing than the heaps (which
I believe is "yes") and are there any drawbacks or divantages (apart
from the extra disk space for the identity column).
This is just a small piece of short-to-mid-term performance improvements.
The mid-to-long-term improvements include more drastic analysis and
redesign. I can't satisfy your curiosity about the origin of these
problems, because I don't know them.
Thanks for any constructive help,
Mike|||> The idea I'm trying to get valid feedback on is: Generally speaking, does
> adding an identity column and a clustered index on that identity column
> give me a performance gain
A gain WHERE? If it's just a heap, then I don't know whether your INSERT
performance will improve, since it shouldn't have much effect on the
physical location of new rows. And I don't know what your queries look
like, so it's tough to comment on that as well. If you are doing a lot of
range queries on dates, for example, it would make much more sense for the
clustered index to be on the column(s) with date-related data.
I would say that the question is very difficult to answer "in general." It
seems like a very haphazard approach to me, and you will probably do better
to spend a day or two analyzing the impact of adding sensible keys
(regardless of whether they are natural or surrogates like identity), where
clustered indexes should be, and why -- e.g. what is each table being used
for, how high is the traffic, and what kind of queries are having
performance issues. If you give it a workload, the index tuning wizard
should give a better suggestion than just a blanket "throw identities on all
tables."
A|||Thanks Alejandro. The identity column was generically chosen to avoid
performance hits during INSERTs and UPDATEs. We aren't looking for the
optimal query performance boost in this but simply any amount of boost.
Getting the optimal boost will take more time to analyze than we have for
the short-term. The optimal boost will come later when we take the time to
do a more detailed analysis.
My main concerns are 1) that we are actually getting a performance boost on
SELECTs just by adding a clustered index (compared to having heap) and 2)
that we aren't introducing anything negative because of the clustered index
being clustered on an identity column created solely for the purpose of the
clustered index.
Thanks,
Mike|||You didn't mention the method you are currently using to determine an
indexing strategy. You can try to infer this by examing the SQL selects, but
using the Show Execution Plan option of Query Analyzer can be more
revealing. Be sure you understand what a clustered index is and how it
affects the physical sorting (or re-sorting) of pages in the table.
"Mike Jansen" <mjansen_nntp@.mail.com> wrote in message
news:%23SSNMtfkFHA.2484@.TK2MSFTNGP15.phx.gbl...
> We are currently addressing many performance issues in an existing
> application. One of the items we are investigating is adding clustered
> indexes to tables that do not have them. Currently, about 90 tables out
> of 200 don't have clustered indexes. The long-term solution is to analyze
> each table and determine what the best clustered index is. As a
> shorter-term solution I've done some analysis to determine what some of
> the best candidates would be by writing a query to analyze primary keys,
> identity columns, and unique indexes. The problem is that many of these
> tables have none of those (primary keys, identity columns, or unique
> indexes).
> With the understanding that this database has much to be redesigned
> (meaning I'm not currently looking for comments on bad design), this is my
> question:
> What are the benefits / divantages of adding an IDENTITY column and a
> CLUSTERED INDEX on that identity column to every table that does not have
> a clustered index, primary key, identity column, and unique index. I'm
> mainly looking for insight into any divantages or problems this will
> cause. The reason for the identity column is that it would be a "safe"
> column to add from an application perspective and would be a decent
> candidate for the clustered index.
> I'm very hesitant about doing this blindly and am sing to find out if
> its feasible in the short-term to gain performance by eliminating heaps in
> this manner without introducing other problems.
> Thanks,
> Mike Jansen
>|||Hey Mike,
Before you do anything in the short term, you need to sit down and
write out a long-term plan. I realize that you (like most of us) are
pressed for time, and are trying to solve the problem as quickly as you
can to move on to bigger issues. However, if you're honest with
yourself, you'd probably admit that many short-term solutions NEVER get
revisited.
I'm not saying that a short-term solution is not a good idea (sometimes
you gotta do what you gotta do); I am saying that you should make sure
that it is a short-term solution. Six months from now, if your shim is
still holding up the table, you may never get around to fixing the
problem. Have a plan to address the problem, even if you can't get to
it today; set a date for fixing the problem. (BTW, I'm lecturing
myself just as much as I'm lecturing you).
In my experience, any table of a reasonable size (and that definition
varies based on performance) will benefit from a clustered index. If
you're doing a lot of INSERTS and UPDATES, the clustered index belongs
on a monotically increasing column (including IDENTITY values, but
timestamps or DateOfInsert columns might make more sense). If your
data is relatively static (lookup values, etc), then a clustered index
will make more sense on columns where you are retrieving a large range
of data. Regardless of where you place it, most tables benefit from
it.
http://msdn.microsoft.com/library/d...>
_05_5h6b.asp
HTH,
Stu|||Mike,
If there are many deletes, then over time a Heap can take up too much
space, which can hurt Select performance. This is something a Clustered
Index can prevent.
Other than that, I can't see how the performance would increase, other
than purely accidental. Without keys, and without analysing the queries,
you are only guessing. And yes, you can hurt performance if you do not
choose the clustered index correctly.
By the way: although a unique index is preferred, the clustered index
does not have to be unique. So I would definitely NOT add an Identity
column. If you have no clue, and there are already indexes on the table,
then you could choose the narrowest nonclustered index and promote it to
be the clustered index. If there are no existing indexes on the table,
you could create the clustered index on the smallest column with the
most distinct values.
But just like everyone is telling you: the real solution is to create a
well thought out, properly normalized data model, with proper keys and
relations. When that is in place, you might not even have to add any
indexes, other than indexed on the foreign key constraints.
HTH,
Gert-Jan
Mike Jansen wrote:
> We are currently addressing many performance issues in an existing
> application. One of the items we are investigating is adding clustered
> indexes to tables that do not have them. Currently, about 90 tables out o
f
> 200 don't have clustered indexes. The long-term solution is to analyze ea
ch
> table and determine what the best clustered index is. As a shorter-term
> solution I've done some analysis to determine what some of the best
> candidates would be by writing a query to analyze primary keys, identity
> columns, and unique indexes. The problem is that many of these tables hav
e
> none of those (primary keys, identity columns, or unique indexes).
> With the understanding that this database has much to be redesigned (meani
ng
> I'm not currently looking for comments on bad design), this is my question
:
> What are the benefits / divantages of adding an IDENTITY column and a
> CLUSTERED INDEX on that identity column to every table that does not have
a
> clustered index, primary key, identity column, and unique index. I'm main
ly
> looking for insight into any divantages or problems this will cause. T
he
> reason for the identity column is that it would be a "safe" column to add
> from an application perspective and would be a decent candidate for the
> clustered index.
> I'm very hesitant about doing this blindly and am sing to find out if i
ts
> feasible in the short-term to gain performance by eliminating heaps in thi
s
> manner without introducing other problems.
> Thanks,
> Mike Jansen|||Apologies if a different version gets posted; for some reason my
earlier post went off into the ether.
I understand your desire to quickly fix the problem so you can move on
to bigger and better things, but a first step to fixing this is to
write out a plan with definitive dates for fixing all of the
performance issues. Don't let this short-term fix become a permanent
part of your solution (again, I'm lecturing myself just as much as I'm
lecturing you).
I have never encountered a situation where a table of reasonable size
could not benefit from a clustered index; putting the index in the
wrong spot could be bad, but in most cases, a clustered index will
improve performance. If you're doing a lot of INSERTS and UPDATES,
then placing a clustered index on a monotonically increasing value (say
a DateEntered field or DateLoaded or a Timestamp) is a good idea to
avoid page splits. If you place a clustered index on a randomly loaded
field (say a UNIQUEIDENTIFIER or a varchar), you run the risk of
fragmentation. If your data doesn't change that much, the risk is
probably acceptable.
Note that non-clustered indexes include pointers to a clustered index,
so changing the clustered index can have downstream effects on your
nonclustered indexing solution. If you have a lot of non-clustered
indexes (which is likely, given the unstructured "design" you
inherited; been there, done that), be prepared to wait a while as they
get rebuilt when you add a clustered index.
HTH,
Stu