Saturday, February 20, 2010 |
|
Thursday, February 11, 2010 |
|
|
Interesting real-world example of what goes on under the hood of SQL Server the other day. We have a routine that locks rows (using REPEATABLE READ) in a transaction that can take some time to run (we simulated 5 minutes). The same tables are accessed from a couple of websites, however as long as they weren't accessing THOSE rows they would be fine to proceed as normal. I know we're mixing and matching our locking models here, but I can't see how it would work (nor do I have the time to investigate any further!) if we were to use an optimistic locking strategy for our update routine. (As an aside, perhaps breaking it into chunks an committing rather than a 5-minute long transaction would help I'm sure) Anyway, we tested in isolation and all was well, however as soon as we try it with the actual system then it fails- the system stops responding. Looking at the query plan, we saw the problem straight away - one of the queries being run by the website was actually doing a table scan. But why? These tables were all indexed where the join was happening. Turns out that SQL Server is clever enough to know when a Table Scan is more efficient than a random access via an index. Because our test data only had a handful of rows, this meant that a Table Scan happened every time. Running the same query on a database with 100000s of records and the table scan disappears, replaced with an Index seek. |
Thursday, February 11, 2010 11:58:48 AM (GMT Standard Time, UTC+00:00) | | Database
|
|
|
|
Thursday, February 04, 2010 |
|
|
http://stackoverflow.com/questions/324771/consuming-remote-web-services-from-client-side-script"From what I understand, due to the "same origin policy" enforcement in current browsers, it's impossible to obtain data from an XmlHttpRequest sent to a different domain than the Javascript's original domain.I have close to zero experience regarding this matter, so I'm confused about web services being unusable from Javascript. Does it mean that web applications with Ajax functionality can only interact with themselves without calling services provided by other domains ? How do "mash-ups" work ? I guess the services are consumed server-side, then the data is passed to the client via local Ajax calls. I don't know. The only way I can imagine to achieve client-side consuming of services would be to retrieve a Javascript file directly from the target web service's domain via a script tag, then use its API to interact with the remote domain. Can anyone enlighten me ?" In your question your mentioned the <script> trick. JSONP is based on that. It was formally proposed almost 3 years ago by Bob Ippolito. It doesn't give you the right to talk to the origin of the script — the origin is defined by your web page, not by what else it includes. It works only because the server wraps JSON in a calback function, which should be defined in your code, and will be executed by <script> when loaded. Most famous example of JSONP would be Yahoo services, including Flickr. Another technique is to use window.name to transfer the information. This technique was detailed by Kris Zyp four month ago. Additionally his article compares window.name transport with JSONP. I don't know any high-profile service provider that supports this new transport. Obviously it will change over time. Of course, I should mention the upcoming Microsoft XDomainRequest. It is being planned to be shipped with IE8, and no other vendors committed to support it, but it was presented for the inclusion in HTML 5. XDR is a useful piece of functionality, but I suspect it'll be changed several times before being accepted. If you looked in the links you probably know by now that all these methods require a certain level of cooperation from a 3rd-party server. You cannot use random services at will. If you do have to use an uncooperative service, the only solution is to proxy it through your own server with all associated problems: the questionable legality, the reduced performance, the increased load on your server, the reduced number of connections between user's browser and your server, and so on.
|
|
|
|
|
Wednesday, January 27, 2010 |
|
|
To get this, you could use an HTTP sniffing tool like Fiddler or HTTPFox, but there may be times that you have problems with this due to proxies etc being used in the company. Thankfully there's a way to output the trace using the code below: <system.diagnostics>
<trace autoflush="true"/>
<sources>
<source name="System.Net" maxdatasize="1024">
<listeners>
<add name="TraceFile"/>
</listeners>
</source>
<source name="System.Net.Sockets" maxdatasize="1024">
<listeners>
<add name="TraceFile"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="TraceFile" type="System.Diagnostics.TextWriterTraceListener" initializeData="trace.log"/>
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose"/>
<add name="System.Net.Sockets" value="Verbose"/>
</switches>
</system.diagnostics>
Acknowledgements to the following post: http://stackoverflow.com/questions/300674/getting-raw-soap-data-from-a-web-reference-client-running-in-aspnet |
Wednesday, January 27, 2010 12:20:01 PM (GMT Standard Time, UTC+00:00) | | ASP.NET | c#
|
|
|
|
Monday, January 25, 2010 |
|
|
Custom sections are created by declaring the section name in the <configsections> element, and then declaring the section, like so: <section name="MyCustomSection" type="System.Configuration.NameValueFileSectionHandler"/>
<MyCustomSection>
<add key="KEY1" value="VAL1"/>
<add key="KEY2" value="VAL2"/>
</MyCustomSection>This is then read in as follows:
NameValueCollection myList= (NameValueCollection)
ConfigurationManager.GetSection("MyCustomSection");
return myList[scenario];Simples. |
Monday, January 25, 2010 1:33:23 PM (GMT Standard Time, UTC+00:00) | | c#
|
|
|
|
Sunday, January 10, 2010 |
|
|
One of my pet projects over the past couple of years has been the development of a mobile data capture system. I recently re-wrote the entire thing for a different project, and have decided it's so good that I want to launch it to the wider world!
If you think this could be of use to you, then check out http://www.mobileelectronicforms.com
|
Sunday, January 10, 2010 10:35:14 PM (GMT Standard Time, UTC+00:00) | |
|
|
|
|
Wednesday, January 06, 2010 |
|
|
I tend to use ViewState in most of my web applications, but when it comes to web sites there's rarely a need for them across all pages. In fact for some sites it can be switched off altogether. However, even setting this in the web.config as so <pages enableSessionState="false" enableViewState="false"> when you View Source there's still a __VIEWSTATE hidden input field. Expected behaviour - as documented here. |
Wednesday, January 06, 2010 9:20:44 PM (GMT Standard Time, UTC+00:00) | | ASP.NET
|
|
|
|
|
|
|
| Archive |
| February, 2010 (3) |
| January, 2010 (6) |
| December, 2009 (4) |
| November, 2009 (4) |
| October, 2009 (5) |
| September, 2009 (3) |
| August, 2009 (4) |
| July, 2009 (2) |
| June, 2009 (7) |
| May, 2009 (3) |
| April, 2009 (4) |
| March, 2009 (1) |
| February, 2009 (2) |
| January, 2009 (4) |
| December, 2008 (6) |
| November, 2008 (4) |
| October, 2008 (1) |
| June, 2008 (2) |
| May, 2008 (1) |
| March, 2008 (5) |
| February, 2008 (3) |
|
|
|
|