Monthly Archives: September 2014

MS SQL Server: Executing SQL Script from Command Line


When opening a 150MB SQL script file in Microsoft SQL Server Management Studio, the following error appears:-


Instead of opening the large SQL script file and execute it, we can execute it directly from command line.

sqlcmd -E -d[database_name] -i[sql_file_path]

… where -E uses trusted connection, -d points to the database and -i points to the SQL script file path.

For example,

sqlcmd -E -dshittydb -ic:\Users\shittyuser\shittydb.sql

IntelliJ: Overriding Log4J Configuration Globally for JUnit


Most of the time, we may have several Log4J configurations depending on the environments, for example:-

  • log4j.xml (Log4J) or log4j2.xml (Log4J2) – Production configuration using socket appender.
  • log4j-dev.xml (Log4J) or log4j2-dev.xml (Log4J2) – Development configuration using console appender.

Since log4j.xml and log4j2.xml are the default configuration files for Log4J and Log4J2, these configurations will always be used unless we override the configuration file path.

In another word, if we don’t override the configuration file path and we run our JUnit test cases offline from IntelliJ, it may take a very long time to execute them due to the broken socket connection. Further, it is not a good idea to clutter our production log files with non-production logs.


To fix this, we need to configure IntelliJ to always use our development Log4J configuration.

First, on the menu bar, select Run -> Edit Configurations...

Then, delete all the existing JUnit configuration files.

Finally, expand Defaults -> JUnit.

Under VM options, specify the following system property:-

  • For Log4J, specify -Dlog4j.configuration=log4j-dev.xml
  • For Log4J2, specify -Dlog4j.configurationFile=log4j2-dev.xml

Please note the slight change on the system property name depending on the Log4J version.

Now, when we run our JUnit test cases from IntelliJ, it will always pick up the correct custom Log4J configuration file.