|
Instead using four single quotes then use CHAR(39)
set @sql=@sql+'update tbl_swbom_checklist_testers set '+@COLUMN+'='+CHAR(39)+@VALUE+CHAR(39)<br />
set @sql=@sql+' where tester='+CHAR(39)+convert(nvarchar(100),@tester)+CHAR(39)+' and package='+CHAR(39)+convert(nvarchar(255),@package)+CHAR(39)
Hope this helepd you.
I Love T-SQL
"Don't torture yourself,let the life to do it for you."
If my post helps you kindly save my time by voting my post.
www.aktualiteti.com
modified on Tuesday, August 4, 2009 11:56 AM
|
|
|
|
|
Hi All,
i want to edit DataSet value before binding to GridView. How can i do that..?
conn.open();
string result="select name,address,age";
sqlCommand cmnd=new sqlCommand(result);
sqlDataAdapter ad=new sqlDataAdapter(result,conn);
DataSet ds=new DataSet();
result.Connection=conn;
ad.SelectCommand=result;
// in here i want to edit (divide age value by 2) before bind data to gridview.
ad.fill(ds);
GridView1.DataSource=ds;
GridView1.DataBind();
conn.close();
i want to divide age value by 2 before bind data to gridview.How can i do that...???
Thank you very much .....
CheeN
|
|
|
|
|
A DataSet object is a collection of DataTable objects. You could loop through the table and update the age with something like this:
For Each row As DataRow In ds.Tables(0).Rows<br />
row("age") = row("age") / 2<br />
Next
Or you could just do it in the select by changing your select statement to this string:
"select name, address, age/2 as age"
Hope this helps.
|
|
|
|
|
Thank u 4 your post. I fixed my problem..Thank u all...
CheeN
|
|
|
|
|
For Each dr As DataRow In ds.Tables(0).Rows
dr("ColumnName") = (dr("ColumnName") / 2)
Next
Where ColumnName is your data column in the DataSet Table.
I don't speak Idiot - please talk slowly and clearly
I don't know what all the fuss is about with America getting it's first black president. Zimbabwe's had one for years and he's sh*t. - Percy Drake , Shrewsbury
Driven to the arms of Heineken by the wife
|
|
|
|
|
Hi Guys,
I'm in need of your help.
my problem is, i have two tables namely MASTER and LINECONTENT.
"MASTER" table contains 5,00,000 records,
The columns in MASTER table is
masterid int, masterdesc varchar(1000).
"LINECONTENT" table contains more than 1000 records &
its columns are pageno int, lineno int, content varchar(2000).
I want to compare each row of "MASTER" table, masterdesc column value with the "LINECONTENT" table content column,
If any records matched i want to take the matched master record and store it in another table.
for this i used the below query.
select b.* from linecontent a
join master b on a.content like '%'+b.masterdesc+'%'
but this query is taking much. more than 15 minutes
i want to decrease the time give me some suggestions handle this problem
thank you
regards,
prakash
|
|
|
|
|
Throw an index on MasterDesc
Try and use charindex in the where clause - it may not help, just an idea.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi,
Thanks for your reply.
sorry i forgot tell you that i have created nonclustered index in both tables. In "MASTER" i have created non-clustered index for masterdesc column similarly in "LINECONTENT" table i have created non-clustered index for "content" field. even though its taking time.
thanks & regards
P.Prakash
|
|
|
|
|
Putting an index on masterdesc will not make any difference to this query because you are using a leading wildcard: LIKE '%abcde%'. The query optimiser will not even try to use an index for this: it will just go through the rows one by one checking each in turn, because that's all it can do.
So basically the query will take every row in LINECONTENT and test it against every row in MASTER. That's why it's taking so long.
|
|
|
|
|
Hi,
but my functionality is like that. i want to compare "master" table with "linecontent" table and matching rows should be taken. so i have written like that but its taking nearly 15 minutes. i want to decrease the time to some 2 to 3 minutes. please tell me the solution
Thanks & Regards,
P.Prakash
|
|
|
|
|
I understand what you are trying to do. The problem is that a leading wildcard search is a performance killer, end of story. There is no quick fix or easy answer.
Depending on which version of SQL Server you are using, you may be able to use Full Text indexing. I can't remember whether that was added at SQL Server 2005 or SQL Server 2008 off the top of my head.
Otherwise, I would recommend looking at something like Lucene or Microsoft Search Server to see how they work, as they do something similar to what you are trying to achieve.
|
|
|
|
|
I wonder if he tested charindex and if it give a better performance. I would be surprised if it did but needs testing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi,
I could not understand what you have said.
Could me please explain me deeply.
Thanks & Regards,
P.Prakash
|
|
|
|
|
Hi,
thanks for your answer,
we are using sql server 2005 i'll look for those two options you have specified.
regards,
P.Prakash
|
|
|
|
|
Hi David Skelly,
for this problem can we use table partition method. will it help me to solve the problem.
Thanks & Regards,
Prakash
|
|
|
|
|
Try this
select master.masterdesc <br />
from master ,linecontent<br />
where master.masterdesc = linecontent.content<br />
I Love T-SQL
"Don't torture yourself,let the life to do it for you."
If my post helps you kindly save my time by voting my post.
www.aktualiteti.com
|
|
|
|
|
Hi,
Thanks for your reply.
i tried for your solution but still i'm having same performance
just give me some solutions
thanks & Regards
Prakash
|
|
|
|
|
|
Hi,
thank u i'm looking for it
regards
Prakash
|
|
|
|
|
I use IDENT_CURRENT to predict the next identity on a table (I know I have to be careful).
IDENT_CURRENT return the SEED value (1) for a never populated table
(it's a bug...https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=297781[^])
and the same value for an empty table with 1 rows inserted and deleted.
so when IDENT_CURRENT return 1 I don't know if the new identity value will be 1 or 2.
I have to exec:
DBCC CHECKIDENT ('table_name', RESEED, 1) --if a table was empty and never populated
DBCC CHECKIDENT ('table_name', RESEED, 0) --if a table was empty and just populated
in this way IDENT_CURRENT will return always 1.
I'm searching for a more elegant solution than, for an empty table, insert a dummy row, get the IDENT_CURRENT and delete the dummy row!
Many thanks to all
|
|
|
|
|
Why don't you use a "select count(*)" statement to determine if the table has any rows in it ? I must be missing something.
|
|
|
|
|
Ok, I try to explain better.
I want to predict what will be the next identity value for a table.
If a table have 1 row inserted and deleted, the table is empty and populated.
I this case IDENT_CURRENT return 1 and the next id value will be 2. Correct.
If a table is empty and never populated IDENT_CURRENT return 1 again (it's a bug) and the next id value will be 1. In this particular circumstance i can't predict the next id value and i would like to kown a way to check if a table was populated or not.
"Select count(*)" don't solve the problem.
Anyway many thanks!
|
|
|
|
|
If your identity field is called something like myIndex, why not just do something like
DECLARE myCounter INT
SET @myCounter = SELECT MAX(myIndex) FROM myTableName
DELETE FROM myTableName WHERE myIndex = @myCounter
|
|
|
|
|
Thanks for replay leckey.
I try to explain better.
I want to predict what will be the next identity value for a table.
If a table has 1 row inserted and deleted, the table is empty and populated.
I this case IDENT_CURRENT return 1 and the next id value will be 2. Correct.
If a table is empty and never populated IDENT_CURRENT return 1 again (it's a bug) and the next id value will be 1. In this particular circumstance i can't predict the next id value and i would like to know a way to check if a table was populated to achieve my goal.
With your code I can't predict the next identity (autonumber) value in the scenario above explained.
Anyway, thanks again.
|
|
|
|
|
IDENT_CURRENT is not a reliable way of predicting the next identity. It can give you a probable value, but you can never be sure of what the next value will be in practice because of concurrent inserts, rollbacks, etc. It will only give you a "best guess" at what the next identity value is likely to be. The bottom line is that you can't predict the next identity, not reliably.
If you need to work around this bug, you could use an insert trigger to update a counter value in another table. That way you can tell how many inserts there have been on your main table. If the counter is 0, your next identity is 1. Otherwise, go and look at IDENT_CURRENT. It's a bit clunky but it's better than doing an insert then a delete.
If you really need 100% predictability of the next identity value, you will probably be better off not using IDENTITY but rolling your own solution (it's not hard - people used to do it all the time before IDENTITY came on the scene). That way you can be completely in control of what value gets allocated to each new insert.
|
|
|
|