ignore my last post...it has been a tiring day =)
b1xml2
@b1xml2
Best posts made by b1xml2
Latest posts made by b1xml2
-
RE: Try/finally or local variable
-
RE: Try/finally or local variable
@b1xml2 said:
with the following snippet:
private void button1_Click(object sender, System.EventArgs e)
{
string value = GetValue();
MessageBox.Show(value);
DataTable table = GetTable();
MessageBox.Show(table.TableName);
}
public string GetValue()
{
string value = "test";
try
{
return value;
}
finally
{
value = "no test";
}
}
public DataTable GetTable()
{
DataTable table = new DataTable("MyTable");
try
{
return table;
}
finally
{
table.TableName = "MyOtherTable";
}
}
In C#, for value types, the finally statement has no impact. But for
reference types, the finally statement does have an impact (since the
objects are on the heap)
Hence:
The first message box will be "Test"
The second message box will be "MyOtherTable"
Either way, such code can be confusing and have unexpected results and really is to be avoided at all costs.
I would like to correct myself. The unexpected behaviour applies to
strings only and not to other value types such as integers. Nonetheless
it is rather interesting to say the least to see such unexpected
results.
-
RE: Try/finally or local variable
with the following snippet:
private void button1_Click(object sender, System.EventArgs e)
{
string value = GetValue();
MessageBox.Show(value);
DataTable table = GetTable();
MessageBox.Show(table.TableName);
}
public string GetValue()
{
string value = "test";
try
{
return value;
}
finally
{
value = "no test";
}
}
public DataTable GetTable()
{
DataTable table = new DataTable("MyTable");
try
{
return table;
}
finally
{
table.TableName = "MyOtherTable";
}
}
In C#, for value types, the finally statement has no impact. But for
reference types, the finally statement does have an impact (since the
objects are on the heap)
Hence:
The first message box will be "Test"
The second message box will be "MyOtherTable"
Either way, such code can be confusing and have unexpected results and really is to be avoided at all costs.
-
RE: Trouble Finding a Date
I have seen too many WTF with regard to ADO.NET. There are lots of developers just being downright abusive to poor ol' .NET
The first WTF is getting the current date from the database server.
Especially if the database is on the same box as the web server (pretty
common). If the database is not on the same box, the web server and the
database server should have their times synchronised
The second WTF is needlessly converting the date to varchar inside SQL
Server. If the developer needs to display the date in a certain format,
he has to "re-parse" the string to the DateTime type and then use the
ToString to get the correct string format.
Please repeat after me. We shall remember to use the CultureInfo object.
The third WTF is abject failure to use the ExecuteScalar.
But what I personnaly find objectionable is the naming conventions. It seems this VB.NET programmer is stuck in the days of VB
The best approach is obviously:
Dim currentDateTime As DateTime = Now
and assuming the code still goes ahead (with serious misgivings)
===========================================
Dim connection As New SqlConnection(...)
Dim dateCommand As New SqlCommand("SELECT GetDate()",connection)
connection.Open()
Dim currentDateTime As DateTime = DirectCast(dateCommand.ExecuteScalar(),DateTime)
connection.Close()
dateCommand.Dispose()
Dim completeMessage As String = currentDateTime.ToString("MM dd yyyy") & " - " & noteMessage & " - CUS"