Rants Tagged with “Databases”
<< < 1 2 3 4 5 > >> (Total Pages: 5/Total Results: 47)
Uh oh, do you think Larry Elisson knows about this?
I've been spending some time lately reviewing how companies are doing data access in .NET. When I look at how most of them have crufted up solutions, I am amazed. The model that Microsoft supports seems so obvious to me, but I am neck deep in it. I'd like to hear from my readers their specific experience with creating data access in .NET; with an eye to why or why not use COM+ for transactions; Typed DataSet or DataReaders; Business Objects or Messages. I am trying to understand where the community is.
Thanks in advance...
A client came across this link to a great workaround for the nasty problem of not being able to put data driven fields or calculated fields in the footer of reports written for
SQL Server Reporting Services. At the bottom is a second link to working around the same thing for database images too!
In response to Sahil Malik's recent post on CLR Types as UDT's in Yukon, I have to say I prefer the Typed Xml in Yukon to CLR Types.
In Yukon there are two paths to creating User Defined Types. The CLR path has some limitations, (primarily the 8K size limititation). I am a big fan of the XML Type path. Typed XML inside the server is a better way to create complex types in the database IMHO. Typed XML is schema based. This means the types in your database can be exposed externally as well if needed (like through web services <some of you might be seeing a pattern emerge here>).
In addition, Microsoft's extensions to XQuery (which I hope the standards board adopt) allow you to do in-place editing of Typed XML which means you don't have to do wholesale replacement of xml documents any longer (or wholesale changes to CLR based UDF's). The syntax allows you to do insert, updates and deletes to individual nodes (or series' of nodes).
In response to your rant about the inelegance of the CLR's null implementation:
I think you're off track here. ADO.NET mirrors the same type dissonance that exists between SQL Datatypes and most programming types. While Nullable<> will help, it isn’t a panecea. We will still need to check for null (or DbNull) values. In your example, I would have:
DataColumn dc = new DataColumn() ;
dc.Name = "TotalCost" ;
dc.type = typeof(money) ;
dc.Expression = "price * quantity" ;
Because this value could (DbNull == true), the resulting value of (price * NULL) is NULL just like in SQL. You could get around this by providing default values, but that just extends the problem.
This seems like an elegant solution…just check for IsNull first:
if (dataRow[“price”] == DbNull.Value)
{ // …
}
Or do it in your expression:
dc.Expression = “isnull(price, 0, price) * isnull(quantity, 0, quantity)”;
Does this make any sense?
Recently I was talking with Rocky Lhotka and he said something interesting:
“Just when we got good at Client-Server, they switched things and had us doing n-Tier applications. Just when we got good at n-Tier development, internet applications took off.”
In my opinion he is right. It is interesting because client-server and n-Tier applications still exist, especially in enterprise development. I think we're good at client-server and n-Tier. The problem is that I think that much of browser based development attempts to apply n-Tier development.
What do I mean? In simple words, the web server is the middle tier. The browser is the client tier.
The idea behind n-Tier development is being able to separate the data work into a tier that can be scaled out. Luckily we know how to scale out webservers (into farms). Since we are securing webservers, we can isolate security issues from the client...just like we've done in n-Tier development.
I've had time lately to think about the nature of data in development lately. I've been talking with Rocky Lhotka and Michael Earls about it (as well as number of others) about the issues with dealing with data in applications.
The first camp is all about writing Business Objects. In this camp, you write classes that encapsulate the data, the data access and business rules about that data. This camp was the way to do it for years now. It proliferated in the Client-Server and n-Tier architecture camps.
Rocky Lhotka espouses his excellent CSLA.NET framework. If you are going the business object road, I wholeheartedly recommend it. It is designed around allowing object to exist locally or on separate servers through remoting.
The second camp is that data is all about data, so data is just a message to some system. With the excitement around Service Oriented Architectures (SOA), this view is starting to prevail.
Somewhere in the middle is where I sit. I think that data and business rules belong together, but the data access can be disconnected from it. So this is the interesting fact in my opinion...there are reasons to have the data access separated from the end users' machines (so perhaps remote data access), but once in the client, you want to have the business logic (and schema) as close to the client as possible. The closer it is to the client, the better it should scale. I don't like to see finely grained data access happening. Even in client-server apps, the more coarsely grained the data access, the better it should scale IMHO.
There is more I want to say on this, so stay tuned. I will be posting every day about this.
Tomorrow: “n-Tier, gone tomorrow”
I was taking a refresher MCSD test today to get ready to take one of the tests and came upon a question that is wrong. But it does infer that there is some confusion about how transactions are propogated to commands...or may be evidence that it is a bug. For example:
SqlConnection conn = null;
SqlTransaction tx = null;
try
{
// Create a new Connection
conn = new SqlConnection("Server=.;Database=Northwind;Integrated Security=true;");
// Open the Connection
conn.Open();
// Start a Transaction and create a new Command
tx = conn.BeginTransaction();
using (SqlCommand cmd = new SqlCommand())
{
// Set the Connection to the command
cmd.Connection = conn;
// NOTE: I do not explicitly set the TX to the Command
//cmd.Transaction = tx;
// Insert new values and execute it
// (within the transaction)
cmd.CommandText = @"INSERT INTO Customers (CustomerID, CompanyName)
VALUES ('ZZZZY', 'My New Company');";
cmd.ExecuteNonQuery();
// Insert new values, but the table name is wrong
cmd.CommandText = @"INSERT INTO Companies (CompanyID) VALUES('ANother Company')";
cmd.ExecuteNonQuery();
// We should never get here since the query is wrong
tx.Commit();
}
}
catch (Exception ex)
{
// Rollback the tx if error'd
if (tx != null) tx.Rollback();
}
finally
{
tx.Dispose();
// Close the connection just in case
if (conn != null)
{
conn.Close();
conn.Dispose();
}
}
This code fails because I do not explicitly set the transaction to the command. Unfortuately, you must set the connection and the transaction. This seems like a bug because you cannot execute a command on the connection (that has an pending transaction) without throwing an error.
The practice test asked me to specify a single missing line of code, so I could either set the command's connection property or it's transaction property, but not both. I suspect that there is confusion inside of MS about what is the expected behavior. But for now, I will just continue to set both and know that the test is wrong....
While trolling the DevelopMentor .NET Lists, William D. Bartholomew mentioned a new UML tool that does round-tripping to and from code. I've used Rational's (IBM's) XDE before to do this, but it is buggy and hates source code control.
Sparx Systems' Enterprise Architect is a great tool. It doesn't work in the VS.NET IDE, but works with it very well. I like several important things about it:
- It does roundtripping of the code with no discernable breadcrumbs.
- It is fast and interfaces with VS.NET pretty clearly.
- It costs next to nothing ($189 for the Professional Edition, and $95 for the VS.NET connector).
- Handles the full spectrum of UML Models (Use, Case, Component, etc.)
- Handles Database Modeling fairly well.
- Auto-Layout actually makes decent looking diagrams.
- Knows to connect objects that have references to each other.
One of the features that really stands out is being able to see the model and code at the same time. Changes to the model affect the code and vice-versa:
I was really surprised by the price, since Rational's XDE is $2,500...nearly 10% of the cost for more of a product.
Go get a copy before they figure out they've under-priced it!
Evidently MS slipped on thier pledge to deliver the betas at the conference. This article implies that they are claiming that the betas are “imminent“...wonder what that really means? Q3? Q4?
UPDATE: Evidently the article is wrong about the VS.NET Beta...hopefully the Yukon beta isn't far behind.
