OK how do you like this: JavaScript in SQL?

Tadas Budvytis

string strSql = "select a.Abr,a.Description As"+ " MaterialType,a.Description,a.code,'" + cm.ChipPath + "'+LEFT(min(m.GraphicID),3)+'/'+min(m.GraphicID)+'.jpg' As ImgPath, " + " Case a.PackageFlag When 'Y' Then '<a href=# " +"onclick=javascript:window.open('/Page/ShowPackageDetails.aspx" "?PK='+a.Abr+'','Package','resizable=no,scrollbars=no,width=1000,height=730,left=50,top=50');>'" + "+a.Description+'</a>' Else a.Description End As MaterialTypeLink " + " from Material_Type a " . . . OK how do you like this: JavaScript in SQL?

J a a n s

Where is the horror? Is it opening a new window in SQL? ;P

*jaans

MarkB777

Yea.. but its javascript!

Mark Brock Click here to view my blog

Yusuf

Tadas Budvytis wrote:

OK how do you like this: JavaScript in SQL?

where is the BEEF :~ I don't see any horror adding JS in sql, but again I don't know the output. I have added js to a code generation. That way I don't have to mack off with the output at the UI level.

Yusuf

Mike Dimmick

I agree completely. String substitution in SQL is pretty stupid (it's not very good at string manipulation), non-parameterized SQL queries are very stupid as they're easily subjected to SQL Injection attacks, and both together (and there's a third language here as well, HTML) is just confusing as all hell. I'd split this up into only retrieving actual values from SQL Server using parameterized queries, writing a real JavaScript function that calls window.open, then writing formatted string code to generate the HTML to call the JavaScript function passing the parameters, and passing that through an HTML/XML entity encoding routine where that turns out to be necessary. As it is, that's an unmaintainable mess.

DoEvents: Generating unexpected recursion since 1991