We work in a field that ... oh ... how do you say ... doesn't quite list "suave" as a top characteristic of its members. Worse yet, we're governed by the Steve Rule (you know, the one that goes something like in a random sample of programmers, there will be more named Steve then there will be females), which makes it even harder for us to find that significant other. After looking at how Sunny Nagi's predecessor would get the current date, the only thing I can possibly fathom is that he must have been subconsciously expressing his frustration in getting a date in real-life ....

Dim notemessage, current_msg, complete_message, thedate, staffemail As String

Dim sqlcmd As New SqlClient.SqlCommand("SELECT thedate=CONVERT(varchar(30),getdate()) ", SqlConn)
Dim sqladp As New SqlDataAdapter(sqlcmd)
Dim dsData As New DataSet

SqlConn.Open

sqladp.Fill(dsData)

' *** Get the date
Dim drow As DataRow
For Each drow In dsData.Tables(0).Rows
  thedate = drow("thedate")
  Exit For
Next

SqlConn.Close

complete_message = thedate & " - " & notemessage & " - CUS "

Querying the database to get the current date... yep, that's a definite WTF.

You can't possibly mean that programs could determine the date PRIOR to SQL Server's creation.

Maybe the database server has the most accurate/reliable time?

What if the SQL server is very far away from the application?

I've never felt the need to comment before .. but that's fabulous!  He's either the kind of person to copypaste his way through life or is just too obstinate to lower himself to anything easier .. bizarre

Hello....The real WTF is that they are using a dataset to get a single value out of the database. Can anyone say ExecuteScalar?

Yeah, this is insane.  DateTime.Now anyone?

Obviously, this is an application relying on some server process, and it needs to know the date on the SQL Server, not on the local machine. Since this application will be deployed worldwide, it's impossible to know whether the SQL Server is on the same side of the International Date Line as the client, and so you have to query the server to find out.

Sweet!

Now THIS is a WTF!

 

 

even if we assume the database server is local to the webserver, perhaps he doesn't want to reformat the output of DateTime.Now to whatever the getdate() format is using DateTimeFormat. Of course, using the for loop to walk through a recordset containing one record appears to be the real WTF.

In addition to using the DB to return the current date, what is especially great about this one is he is also further misusing the DB layer to do formatting on the date returned, by converting it to a varchar !

Correct me if I'm wrong, but in VB isn't

Dim a, b, c as integer

The equivalent of

Dim a as variant
Dim b as variant
Dim c as integer

?

Oh, yes, and an extra 5 points off for concatenating strings instead of using StringBuilder.

pjabbott wrote:

Correct me if I'm wrong, but in VB isn't Dim a, b, c as integer The equivalent of Dim a as variant Dim b as variant Dim c as integer ?

No, they fixed that in VB.NET.

pjabbott wrote:

Oh, yes, and an extra 5 points off for concatenating strings instead of using StringBuilder.

StringBuilder should be used for repetion, if you are manipulating a string over and over and over.  For things like this, there is absolutely no reason to use a stringBuilder -- in fact, using StringBuilder, which is more of a heavyweight class than string, probably would make things slightly *slower* if it has any effect at all.

A common beginner mistake is that programmers see concatenation anywhere and they think "concatenation? I must use a stringbuilder!" and they make things more complicated than they need to be.

Jeff S wrote:

pjabbott wrote: Correct me if I'm wrong, but in VB isn't Dim a, b, c as integer The equivalent of Dim a as variant Dim b as variant Dim c as integer ? No, they fixed that in VB.NET.

To clarify ...Dim a,b,c As Integer

VB6: Declares "c" as an Integer, "a" and "b" as Variant

VB.NET: Declares all as Integer

< Edited thx to Erik Juhlin >

Anonymous wrote:

Obviously, this is an application relying on some server process, and it needs to know the date on the SQL Server, not on the local machine. Since this application will be deployed worldwide, it's impossible to know whether the SQL Server is on the same side of the International Date Line as the client, and so you have to query the server to find out.

I've seen things like this (not exactly but similar) in client applications.  There is no way to determine whether the client's machine has the proper date.

Let's say your application won't let certain records be updated after a certain period of time (there are other probably better ways to do this but bear with me.)  Time on users machine is wrong. User goes in and updates the document even though the time period is over.

Anonymous wrote:

Obviously, this is an application relying on some server process, and it needs to know the date on the SQL Server, not on the local machine. Since this application will be deployed worldwide, it's impossible to know whether the SQL Server is on the same side of the International Date Line as the client, and so you have to query the server to find out.

...and this would be why we have UTC time.  For .Net, this is simple as DateTime.UtcNow.

When in doubt, RTFM.

It was mentioned earlier, but it is worth repeating: the other WTF is working with DataAdapter, DataSet, DataTable, and DataRow objects when a simple ExecuteScalar() is all that is needed to return a single value from a command object in ADO.NET.

By the way, great intro as usual Alex ! 

Oh, one more thing: I like the "loop" that takes the first value and then just exits ....

 

 

Anonymous wrote:

...and this would be why we have UTC time.  For .Net, this is simple as DateTime.UtcNow. When in doubt, RTFM.

Is there a way to make sure the client machine's time clock is set to the correct time?

This is valid if the DB has the time that's critical to the rest of the system, and since you normally do things like insert a record using getDate(), then all those dates, etc, have the DB's time.

Once, I took over a system that assumed everything was in pacific time, which was fine until part of it was moved into central time...

Also- -FREQUENTLY- clocks skew too much and you can't rely on IT to get their act together, so you pick a time authority like the most important DB and get on with it.

The WTF is why there isn't a function that he's calling rather than just inlining the qry, etc. And a comment would be cool too.

Should read- "asking the DB for the current date/time is valid in some scenarios"...

(couldn't edit my previous post)

The rest of the code, I won't vouch for.

Please don't hurt me, but I actually wrote something just like this at a previous job. I think it was in VB 4.0 16-bit.

There was a rounding issue with some (very large) dollar amounts. Whenever I would do a certain calculation in VB, the result would always be off by a penny. I did days and days of research on the problem. I don't remember the specifics of the problem, but I'm sure others here have heard of this issue, because it was a result of how certain Base-10 numbers become repeating decimals when stored in binary.

Anyway, VB 4 had this issue. But after a while, I realised SQL Server 6.5 did not have this issue. So finally, I used ODBC API functions to connect to SQL Server, perform the calculation there, and return the result.

God. I'm just waiting for someone at my former company to submit that WTF to this site.

 

memorex wrote:

Also- -FREQUENTLY- clocks skew too much and you can't rely on IT to get their act together, so you pick a time authority like the most important DB and get on with it.

Don't you know IT staff have more important things to do than to walk around the office, setting computer clocks to the right time?

A Wizard A True Star wrote:

Please don't hurt me, but I actually wrote something just like this at a previous job. I think it was in VB 4.0 16-bit. There was a rounding issue with some (very large) dollar amounts. Whenever I would do a certain calculation in VB, the result would always be off by a penny. I did days and days of research on the problem. I don't remember the specifics of the problem, but I'm sure others here have heard of this issue, because it was a result of how certain Base-10 numbers become repeating decimals when stored in binary. Anyway, VB 4 had this issue. But after a while, I realised SQL Server 6.5 did not have this issue. So finally, I used ODBC API functions to connect to SQL Server, perform the calculation there, and return the result. God. I'm just waiting for someone at my former company to submit that WTF to this site.

http://docs.sun.com/source/806-3568/ncg_goldberg.html

Sun didn't write the above so you softies can read it without asking your dark overlord for permission.

loneprogrammer wrote:

memorex wrote: Also- -FREQUENTLY- clocks skew too much and you can't rely on IT to get their act together, so you pick a time authority like the most important DB and get on with it. Don't you know IT staff have more important things to do than to walk around the office, setting computer clocks to the right time?

Geez, what the hell is this NTP thingy?  I turned it off on all my rooters because it didn't look important. But, why won't my Windows stations syncronize with the time server?