Igor Sukhov

Every computer-based algorithm cannot be considered 100% random because it's generates sequence of pseudo-random values. If you want to improve randomness while using Random class use the overloaded version of ctor which accepts an integer as a "seed" value.

Caching reasonably large amounts of data (size of a dataset is the kind of animal that tends to grow beyond expectations) on the client side could be troublesome (not taking into account security and performance implications) *you need to implement client-side caching mechanism (persistence, expiration, etc) using script code *you also need to write some script code to populate/update client side UI (it might not be a problem if you already using script on the client side though) Therefore, I recommend storing a dataset in the session state stored on the server. By storing it in the session each user will have its own copy of data and session will also take care about cleaning up memory upon session's expiration. However the main reason to implement caching on the server is what you would need to write less code and this code going to be much simpler (especially if you're using ASP.NET) compared to a client side, script-based implementations.

What do you mean by "rules" ? How do you apply/convert your "rules" to actual XPath expressions ?

To append an element to XmlDocument you have to go thru these three simple steps: * Find a place where exactly you want new element to be place. This can be done using XPath queries (this it the preferred way - see SelectSingleNode method in MSDN) or by iterating thru XmlDocuments object model (which is only reasonable in case of small documents with simple structure). As a result of your search you would have a reference to XmlNode object - the future parent for new 'to-be-created' node. * Find a node you want to make a copy. When that node is found - clone it by using, comes with no surprise, 'Clone' method. * Append duplicate (created at the previous step) to the parent node (found at first step) using AppendChild method. That's all. ps: and don't forget to save changed XmlDocument.

Following xpath query returns all Book elements which child CATEGORIES element contains string "2": "//Book[contains(CATEGORIES/text(), '2')]"

I can't agree. Obviously, multi CPU's boxes utilizing several processors are better suited to handle "wait scenarios", but the actual benefit of WaitSpin (saving time not going into the kernel mode) function (and the Win32 functions used to implement that it) doesn't require machine to have several CPUs.

I don't think it has anything to do with the ‘hyper threading’ or multi CPU's. SpinWait does not cause system to switch to the kernel mode hence saving lot of precious CPU ticks required for transition from user mode to kernel mode. Of course if only pays off in the situation when only small delay is required. Therefore, consequent calls to Thread.Wait could potencially void any performance benefits gained by remaining in user mode. The Win32 "critical sections" employ the similar waiting strategy trying to wait in the user mode first.

I've recently heard the same "there's no need for locally installed MSDN as Google way faster" thing recently. I've been using MSDN since 1998 and although internet search engines have changed my search habits drastically I reckon there's a still few points to have it locally installed: *I've got quite fast broadband connection but local MSDN library is still a quickest way to do a lookup for a method prototype (intelliscence doesn't give me all the information I usually need), list of methods defined by class or implemented interfaces. *When I'm searching for articles in MSDN I'm quite sure that the information I would find be from technology experts. *MSDN library is reasonable well structured and carefully maintained - hence providing good "surf-explore" experience. *You've made a good point about not having internet connection or if it became too slow to be usable. *I've got 0.75 of terabyte space on my PC :cool: and half of this space is still free. Considering all above, I don't think that I'm going to give up installing local MSDN library for at least two coming years.

Thought ASP.NET Web Forms and Windows Forms might sounds very similiar they employ very different application development aproaches. Therefore I strongly recomend to give up implementing this "cursor position" feature in the web application.

What type of the "Custom7" column ? Do you have any triggers on the table you're working on ? I've mentined that your code works correctly on another machine, is that machine uses the same SQL Server ? Does that machine have the same " "regional and language" settings?

Implement server side SOAP extension that "patches" request by replasing "<systemId>" Xml element with "ns1:systemId".

You don't need to be concerned - all you need is to run the test to find out what may go wrong after you had your application deployed. Does main application load plugins into the main application domain or each plugin "lives" in the separate application domain?

Create FOR INSERT trigger for this table. In trigger's code update value of the column.

DataGridView uses GDI+ drawing engine and for this reason it's rather slow. Wait for video cards with built-in GDI+ accelerators or start using 3rd party grid controls.