Asynchronous Client-Server Interaction:
Hidden frame, using top/parent frame's variables to retain scope == HMLHTTPRequest (so long as the returned HTML is not significantly larger than the returned XML would be)
So long as the majority of server requests is nearly instantaneous, where "waiting for the user to pick something" is orders of magnitude more time consuming than processing the decision (which seemed to be true in 99.99% of all cases)...
The client was notified by the hidden frame calling (onload) a function in the parent/top frame. No big deal. In fact, is not this more efficient than weighing down the client script with the duty of monitoring/listening ....?
Sunday, June 20, 2010
Constituent Parts
...and so begins my Useful Phrases page, kind of like the Good Jargon side of Jargon. Maybe I'll have a Good Jargon page and Bad Jargon page. Or a Useful Jargon....you get the point.
Jargon is tremendously important. Can't be overstated. It signals to other parties that you already understand (supposedly) a whole bunch o' stuff, per each Jargon uttered. For the most part, in day to day life, I've seen it as a Bad Thing...it seems to have more drawbacks than benefits in what I've witnessed. Specifically, when switching back and forth between different programmer cultures (Windows vs. Linux, VB vs Java, etc), it is a major hindrance and causes more confusion than necessary. Often it seems Microsoft has deliberately adopted its own terms for Jargon that would otherwise be common between the two camps.
But I'm trying to adopt a more positive outlook on the matter. In either case, Jargon is Very Helpful when it comes to Documentation, in particular, making documentation Brief.
The other great benefit to Jargon is in exposing the genealogy of concepts. Much Jargon in programming is from upper level Mathematics, or Electrical Engineering.
Jargon is tremendously important. Can't be overstated. It signals to other parties that you already understand (supposedly) a whole bunch o' stuff, per each Jargon uttered. For the most part, in day to day life, I've seen it as a Bad Thing...it seems to have more drawbacks than benefits in what I've witnessed. Specifically, when switching back and forth between different programmer cultures (Windows vs. Linux, VB vs Java, etc), it is a major hindrance and causes more confusion than necessary. Often it seems Microsoft has deliberately adopted its own terms for Jargon that would otherwise be common between the two camps.
But I'm trying to adopt a more positive outlook on the matter. In either case, Jargon is Very Helpful when it comes to Documentation, in particular, making documentation Brief.
The other great benefit to Jargon is in exposing the genealogy of concepts. Much Jargon in programming is from upper level Mathematics, or Electrical Engineering.
Thursday, June 3, 2010
Retrieving text stored as an Image data type in SQL Server
So, you have an old database that relies on the Image data type to story rich text, and within the confines of SQL Management Studio, you want to read the contents. Turns out that the Image data type cannot convert to a varchar directly, like some of the newer binary data types can.
So you have to first translate it to binary and then convert that to varchar.
Incidentally, to get the size of the image data, use DATALENGTH (instead of LEN).
So you have to first translate it to binary and then convert that to varchar.
SELECT CONVERT(VARCHAR(8000),CONVERT(VARBINARY(8000),notepad_textimage)) from notepad
Incidentally, to get the size of the image data, use DATALENGTH (instead of LEN).
Subscribe to:
Posts (Atom)