A Date Check - To Narrow Down the Problem

I was facing an issue this week, wrong date of birth was shown for all the patients. When I look at closer, all the patients had same date of birth as "Jan/1/1970". Then I understood that "Jan/1/1970" must be the default date value of .net/sql server. It means somewhere we missed to assign the value for DOB field. Later we figured out, that it was a javascript issue. "Jan/1/1970" is the default date value of javascript. We missed to assign javascript DOB variable. So, as soon as you see "1970" instead of some other value, you can guess that something goes wrong in javascript.

.Net default date value is Jan-01-0001

Sql server default date value is NULL, starts from Jan-01-1753

Oracle default date value is NULL, starts from Jan-01-4712

Javascript default value is Jan-01-1970

Why @@SERVERNAME Returns NULL?

The @@SERVERNAME can return NULL, when you accidentally delete the server. Most probably by this query

sp_dropserver '<ServerName>'

After the SQL Server restart, the @@SERVERNAME started returning NULL. You can confirm this; if the following query returns no records, the local server was deleted.

Select * From sys.servers Where server_id=0

Solution 1

Run the following query to add the server back.

sp_addserver '<ServerName>',local

Solution 2

I would recommend you to use

Select ServerProperty('ServerName')

This approach returns the machine name, even if the sever name is not present in the sys.servers table.

The SQL Profiler Secures Username and Password

Whenever you run a login related query, the SQL Profiler converts the credentials as ‘----’ (hyphens). This feature improves SQL server security.

For example when you run this query

EXEC sp_addlogin 'Victoria', 'B1r12-36';

The profiler hides the username and password by substituting with hyphens

--*sp_addlogin---------------------------

Similar way, when you run sp_addlinkedsrvlogin, it will display as

--*sp_addlinkedsrvlogin---------------------------

Designing a Wrapper

Here I am sharing my experience with wrappers. This article is intended for beginners. Nowadays it is a fashion to create a wrapper for every third party library. The theme of this article is to think beyond the present situation. An unnecessarily created wrapper or a poorly designed wrapper will lead to messy code.

Wrappers created only for the two reasons.

1. Wrapper provides abstraction to a library and makes the developer life easy.
Example: When you have a third party library which has wide range of functionality, but your application needs only very few of them. You should create a wrapper
2. Wrapper enforces best coding practices of the product to use a third party library.
Example: When there are many options in the third party library but few of the options can only be compatible with your application; you should hide/abstract others.

Points to consider when designing a wrapper

1. Ask yourself, are you extending the functionality by a wrapper? If that is the case go for extension methods (C#). Unless until you have a solid reason, don’t create a wrapper.
2. Look around! You may get lot of wrappers from online. But, you need to validate them properly whether it fits your needs and has it well designed. I can see lot of wrappers in code project.
3. Never create a wrapper with reflection or dynamic calls. The degree of dynamism should be very minimal. In my experience introducing generic types are the maximum limit for designing a wrapper with dynamism. Because of dynamism, when there is a bug, the developer can’t even search it them in Google and can’t get help from any online forum. The wrapper should be very simple and neat.
4. A poorly designed wrapper restricts thinking ability; you should decide what level of abstraction is needed.

   Example: One of the NHibernate wrappers didn’t allow me to write QueryOver for sub queries. I couldn’t alter the wrapper immediately, because it has dynamic and reflection calls. To understand those dynamic calls, it would have been taken 2 more days. I had to find alternative way.

5. Think about production issues; never leave a wrapper half-way designed. The wrapper should cover all functionalities of the third party library. You should not design it for the present situation; if the third party library is too big, at least your wrapper should have some guidelines in future if some others want to extend the wrapper. When there is a production issue comes in, developers are forced to fix them as soon as possible. When they fix bugs, they generally don’t alter/extend the wrapper’s design. The code will become messy when the developer finds alternative way to fix the bug.

   Example: We faced a production issue, w3wp.exe was crashing. All our sites were down. The reason was, the wrapper for SqlConnection didn’t handle the SqlDataReader’s close operation. As open connections were not closed, the number of connections crossed the maximum limit and crashed the application. Instead of redesigning the wrapper, we first closed all the opened connections properly by typing “sqlConn.Close()” in 72 places of the application. Then we took time to refine the wrapper.

6. Writing wrappers often lead to performance problems. You should be careful on that.

Why Scala Becomes So Popular?

This article is intended for developers who have an agenda to learn at least one programming language in a year. I recommend them to go for Scala this year. Also I strongly believe Scala can become the next best programming language. Here are the reasons.

1. Scala runs on JVM; takes all the advantages of JVM. Scala is platform independent, object oriented and strongly typed.
2. Scala has well structured type system than Java. Scala uses unified type system as in C#. For an example, all the types are derived from the base type “Any”. “Nothing” is a subtype of everything and not super type of anything.
3. Scala syntax is similar to Java. Scala is easier to learn than any other functional language.
4. You don't have to worry about third party tools for Scala. Third party tools and libraries for Java are matured. Almost all the Java development tools can also be used for Scala. For an example, JUnit can be used as unit testing framework for Scala.
5. Scala is functional. Functional languages are suitable for scalable architectures. In theory functional languages don't allow to alter the variable's state. All the variables are immutable. (In that way, Haskell is a pure functional language, you can't change the state at all.) The advantage of immutability is thread-safe. You can apply parallelism and threading concepts even if the system is so big and rapidly increasing in size. Scala gives good support for concurrency.
6. Scala has very good open source IDE supports. I prefer to use Eclipse plug-in for Scala. IntelliJ IDEA from JetBrians is also a good one. The community edition of IntelliJ IDEA is free. Visual Studio plug-in for Scala is also available here.

Comparison with other functional languages

1. Haskell is another powerful functional language, but it needs a deep learning curve. It doesn't have proper open source editor. The third party tools and libraries for Haskell are not matured enough. Building and installing GHC (Glasgow Haskell Compiler) is very harder than Scala installation.
2. Though Python is matured and functional, Python has limited support for functional paradigm. Python is not considered for enterprise systems. One of our products in Python didn't scale and faced severe performance problems. Python is suitable for string manipulation or string search based applications. Python is best suited for dynamic programming, so comparing Scala with Python is not fair. (My guess is Groovy may overtake Python in near feature. Groovy also runs on JVM.)
3. Like any other functional languages Scala compiler supports type erasure and type inference. Checked exceptions in Java is annoying. This is eliminated from Scala. Scala has a lot of developer friendly improvements from Java.
4. Like F#, Scala also supports multi-paradigm (functional and imperative). One of the reason F# seems to be scary to me is its syntax. Scala syntax is similar to Java, But F# syntax is not similar to C#. See Here. Scala is much more minimalistic language than F#. Scala has a very small orthogonal set of constructs that are re-used throughout the language. F# seems to introduce new syntax for every little thing, thus becoming very syntax heavy as compared to Scala. Scala has 40 keywords, whereas F# has 97”.
5. Also you can find currying, tuples, anonymous functions, pattern matching and lazy evaluation in Scala.

Clojure is also getting popular. Since I don't have knowledge on Clojure or LISP, I can't compare with Clojure.

Any talk on languages is controversial, the above points are my personal views. I welcome your feedback.