Rants Tagged with “ASP.NET”
<< < 1 2 3 4 > >> (Total Pages: 4/Total Results: 40)
I've blogged before about issues with the SqlDataSource. I've crufted up an example of the problems that can be downloaded here (with usual caveat of changing the connection string in the web.config to point to a DB with the Northwind database).
There are three basic issues:
- The problem is that if a database allows nulls (and a specific row has an NULL) then the automagically created queries in the SqlDataSource will affect zero rows. So data loss can happen without alerting the user.
- The other related issue is that if an Update fires and affects zero rows it is swallowed unless the user handles the DataSource.Selected event.
- Lastly, if your query includes SQL Server Timestamp fields, the SqlDataSource designer doesn't know how to handle it correctly (either by inserting it into the Keys field of the control, or that it isn't a varbinary field).
I want the ASP.NET team to use the SqlCommandBuilder so that we have a common SQL Generationh platform so problems fixed in one place don't re-rear their heads.
In general you can get around these issues by hand-crafting your own SQL (or preferrably using Stored Procs) and handing the Updated and Deleted events in your DataSources. The problem with this is that since SqlDataSources seem to be a good RAD-type tool, then they should work in most databases 'out of the box' and they don't.
Any comments on the code or this issue are certainly welcomed!
Big thanks to Scott Guthrie in championing the Web Application for ASP.NET 2.0! I love using the old ASP.NET model (instead of the ackward Web Site project). I have now completely converted to the new format and I am very happy with the way it worked in almost every way.
+1
(If anyone notices anything not working, please feel free to send me an email here).
On Fritz Onion's blog, he mentions that the manuscript for Essential ASP.NET 2.0 should be done by Monday. I am itching to get a copy of that book when it comes out.
I've been scratching my head at the ASP.NET 2.0 TreeView control. This control is meant to show a tree of items and each item can have a link to it. For example, this is what I use for my menu on the left of the page.
It works great, except I had a specific case where I wanted to use it. I have a form for data entry where there is a hierarchy of items to select from. The user picks an item from the tree view and I read the Path of the TreeView control and store it as the selected item. This worked but everytime the user selected an item, I was getting a post-back to the server. It was as if AutoPostback had been enabled. But the TreeView control doesn’t have an AutoPostback property. I noticed that if I set the node’s NavigateUrl property that clicking on a node didn’t call __DoPostBack, but instead called the URL I specified in the NavigateUrl property. So I decided to make the NavigateUrl property “javascript:void(0)”. Essentially telling it that when the item is clicked, do nothing.
But it didn’t work. What was happening was that the control expected to navigate away from the current page, so selecting the item in the control did not matter. It simply ignored the “selection” process.
It was time to dig out Lutz Roeder’s Reflector to see what the TreeView was doing. I dove pretty deep into the actual rendering code of each node. I thought I was stuck or perhaps was going to having to cruft up some nasty hack using reflection to specify a NagivateUrl that would do the selection for me. That’s when I saw it. In the code, if you specify a Target for the node (or the entire TreeView) it will make the Selection code happen.
Why does it do this? It works this way because if the Target of the NavigateUrl is not the current page (e.g. Target=_blank or Target=SomeFrame), then the page isn’t going to change. Therefore, it needs to mark the current item as selected.
This left me a hacky way to my solution. I would specify the Target=”_self”, and NavigateUrl=”javascript:void(0)”. For example:
<asp:TreeView ID="TreeView1"
runat="server"
Target="_self">
<Nodes>
<asp:TreeNode Text="One"
NavigateUrl="javascript:void(0)" >
<asp:TreeNode Text="Two"
NavigateUrl="javascript:void(0)" />
</asp:TreeNode>
</Nodes>
<SelectedNodeStyle Font-Bold="True" />
</asp:TreeView>
Not an elegant solution, but a workable one.
Caveat:
I was helping a friend out this evening trying to get a simple GridView working with a HyperLinkField from a database result and we ran into an interesting security feature that people might run into:
If you add a HyperLinkField to a GridView's Columns to allow a hyperlink in a column (pretty standard), it will create hyperlinks unless the URL starts with something other than http:// and https://. In our case, his DB has an URL of:
FILE://\\somemachine\someshare\somefile.txt
Because it was a full URL but didn't start with http or https, it didn't show the link. Change it to:
\\somemachine\someshare\somefile.txt
If you're interested, there was a Bug Report filed and MS explained why they did it:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=0400b837-db21-4828-90c7-4df607795501
As some of you know I lost the screen on my main laptop (HP ZD8000, a lovely machine at 13 lbs) so I sent it into support where they are going to fix it but take 2 weeks to do it. I took over my old laptop from my dear Tricia to try and make it work for a while.
To simplify her world, the laptop only had XP Home on it. After getting the 3,000 things installed I needed to in order to work on my current project I am going to have to upgrade it to Professional. The problem? ASP.NET 2.0.
I am working on a project using the VS web server (not IIS would would have been an obvious Professional requirement). But I started to get the dreaded "Unable to attach. Binding Invalid Handle" error when trying to debug. Digging deeper it seems that it needs the VS Remote Debugger to work to debug in the VS Web Server (don't ask me why...it *just* does).
Remote Debugger was running, so what was wrong I wondered? I couldn't even attach to other processes with a similarly cryptic error:
"Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor name 'XXXX'. The binding handle is invalid."
So I dug in the debugger (Program Files\Microsoft Visual Studio 8\Common7\ide\Remote Debugger\x86\msvsmon.exe) and ran it manually (after stopping the service). It complained:
"Visual Studio Remote Debugging Monitor will not be able to debug applicaitons because the 'Network access: Sharing and security model for local accounts' local security option is set to 'Guest only - local users authenticate as Guest'. This can be configured with the 'Local Security Settings' administration tool."
Great error message...a solution right? Well, um...nope. Local Security Settings is a tool that only works with XP Professional. So I give up. I am going to do the upgrade to professional and hope I don't hose the machine and have to start all over.
Wish me luck...
This is freaking huge in my opinion. It seems that all the fuss about how hard ASP.NET 2.0 has made it for many of us has gotten through to the team (yeah!). You can download the Preview here:
http://webproject.scottgu.com/
According to this post (this highlights my belief that MS is discouraging DataSets enough though they are using them everywhere (e.g. inside DataSources)). SInce Typed DataSets don't work out of the box with ObjectDataSources, we are left with three uncomfortable solutions:
- Ditch them and write Business Objects even in small apps
- Use SqlDataSources and don't allow NULL's in any of our columns (see my previous rant).
- Write a wrapper class around every DataTable (or perhaps in the partial class) to allow the Object DataSource to work with it.
The Partial Class solution may be easiest, but it is still some magical mix of parameters that will make it appear in the ObjectDataSource configuration dialog. I hope to have a better solution soon for this, but don't count on it.
I've been working on a problem for a client's project. We are doing pretty raw RAD design for a small intranet project so I thought, hey let's just do SqlDataSources to get the pages up and running fast. This works fine *if* we don't want any concurrency.
Let me repeat that, this works fine *if* we do not want concurrency.
The problem lies in the fact that we have columns that are null-able (pretty common in schema design). The concurrency that is generated by ASP.NET 2.0's SqlDataSource does not do the same concurrency (e.g. WHILE foo = @foo OR (foo is null and @foo is null)) that Typed DataSets and CommandBuilders have done for several years.
My guess is that this is another example of how fractured the data teams in Microsoft are. One team does DataSets, which another does Typed DataSets, and if I am correct, yet another does the DataSource work.
Arg!
Michael Earls' blog has a quick 411 on the new Web Project Beta from Microsoft that includes support for pre-building all the assemblies into a single assembly for deployment. Check it out if you're doing anything with
ASP.NET 2.0.
