News Focus
News Focus
Followers 210
Posts 7903
Boards Moderated 15
Alias Born 05/24/2001

Re: stack post# 865

Tuesday, 12/14/2004 6:26:49 PM

Tuesday, December 14, 2004 6:26:49 PM

Post# of 985
I wouldn't be able to use existing routines for this because existing batch-reading routines work on a *range* of message numbers rather than a *list* of them, which is what a search-triggered one would have to deal with.

But I'll still look into it later. This week I want to tackle mostly quickie projects. That one does sound useful and (more importantly to me sometimes) a lot of fun to tackle and come up with a solution for it, but it'll require a lot of thought and potentially a lot of code-banging.

At face value it seems I could use a similar proc and instead of having something like "WHERE subjectid=@subjid AND subjmsgnum > @lbound AND subjmsgnum <= @ ubound", I might be able to use a similar proc but have "WHERE messageid=@msgid1 OR messageid=@msgid2..." Well, no, that wouldn't work. I'd have to know how many messages were going to be retrieved when writing the proc. If I wrote it for 10, and only 5 result messageid were submitted, the proc would throw an error.

Something like "WHERE messageid+',' IN (@msgidlist)" *might* work, but I'm not sure if it'll work well, or even if it'll let me tack a comma onto the end of messageid (integer) like that, since @msgidlist would have to be comma-delimited or asking for messageid '12345678' would return messages 1 through 8, and message 12, message 23.... message 123..... etc.

I use this trick of tacking commas onto the ends of strings and using IN on a comma-delimited list all the time, but am not sure I can do the same with an integer.

Discover What Traders Are Watching

Explore small cap ideas before they hit the headlines.

Join Today