DEV Community: guennithegun

Move your sql database files to a separate hard drive

guennithegun — Fri, 04 Dec 2020 09:16:59 +0000

My company provides me with a development server for my work. Here runs my local version of our application with my git branches for development. This server also runs an MSSQL Server which provides me with a copy of our production database. After some time the free disk space on this server hard drive became smaller and smaller, so I wanted to clean it up.

But I realized that there was not much I could clean up. I noticed the large size of the database files, > 30GB. So I asked our IT infrastructure team to add more disk space to my development server.

As a result, they kept the size, but provided me an additional hard drive, and asked me to move the DB files to the additional hard drive.

So I did some research on how to move only the database files to a different hard drive. Here is what I found out and worked for me well.

1. where are the relevant database files?

First, we need to find out where the relevant database files are stored so that we can copy them to the new hard drive. I found out that you need to move two files, a .mdf and .ldf file.

The .mdf file contains the schema and data. The .ldf file contains the logs. This StackOverflow post gives you a brief overview of these file types.

So now we know which files to copy, we can get the path by using the following SQL query.

select * from [YOUR_DATABASE_NAME].sys.database_files

This will give you the following output (I blurred sensitive information):

2. copy the files to the new hard disk

Now, that we know the path we have to take the database offline to copy the files. Otherwise, you will get an error message while copying, because the files are in use of the database.

I use the SQL Server Management Studio. Here you have to do a right-click on your database, go to tasks, and then click "Take offline". After that you will see something like this:

You have to select the checkbox in the middle. After the database is offline you can copy the two files into your target path on the new hard drive.

Then bring the database online again.

3. pointing to the files in the new path

To point the mssql server to the new file path you have to run two queries, one for each file. For the .mdf file:

ALTER DATABASE [YOUR_DATABASE_NAME]
MODIFY FILE (
    NAME = 'YOUR_NAME_Data',
    FILENAME = 'E:\SQL_DATABASES\YOUR_FILENAME.mdf'
)
GO

And for the .ldf file:

ALTER DATABASE [YOUR_DATABASE_NAME]
MODIFY FILE (
    NAME = 'YOUR_NAME_Log',
    FILENAME = 'E:\SQL_DATABASES\YOUR_FILENAME.ldf'
)
GO

The FILENAME is self-explanatory. The correct NAME value can be found when you do a right-click on the database, then properties. There you can go to Files and will see your individual NAME values in the Logical Name column.

After you run the ALTER query you will get something like this (for the .ldf file as an example):

Very good!

Now we can run the SELECT query from above again and you should get the new paths.

4. restart the SQL server

In my case, I had to do a restart of the SQL server. After that, you also see the new file paths in the properties of the database.

5. free disk space

Now you can delete the .mdf and .ldf files in the origin directory. This is a double-check of your work at the same time because you can not delete these files if they are still in use.

Well done. Your database files are moved to the new hard drive and you are looking forward to new free disk space.

6. Conclusion

I never had to do something like that before. I had fun researching a solution and making it all work in the end. Maybe there are better approaches to this and other best practices. If so please comment and/or reach out. I am happy with any kind of feedback.

Happy Coding!

Be strict: 'use strict';!

guennithegun — Tue, 31 Dec 2019 05:54:32 +0000

The strict mode of JavaScript was introduced with ECMAScript 5. With the strict mode you can opt in to a restricted variant of JavaScript to write better JS programs.

Using strict mode results in several changes to normal JS:

it eliminates some silent errors by changing them to throw errors
code in strict mode can sometimes be made to run faster than identical code written in sloppy mode
prohibits some syntax likely to be defined in future versions of ECMAScript

How to opt in strict mode (opt out sloppy mode)?

You can opt in strict mode per program (means per file!) like this:

// only whitespace or comments allowed before strict mode
'use strict';

// run some code in strict mode

The strict mode snippet must appear on top of the file and only whitespace and comments are allowed in front of it.

You can turn on the strict mode in per-function scope, too.

function whoIsJohnGalt() {
  // only whitespace or comments allowed before strict mode
  'use strict';

  // run some code in strict mode
}

Note that the function-level strict mode is disallowed if the program (file) has strict mode turned on on top. So you have to choose between one or the other.

The only reason to use the per-function scope is when you want to convert an existing sloppy mode file and need to make the changes little by little over time. Otherwise use strict mode for the whole program.

A third way to enter strict mode is using JS modules introduced by ECMAScript 2015. JS modules are automatically in strict mode, with no statement needed to initiate it.

function whoIsJohnGalt() {

  // I am strict by default because I am a module

}

export default whoIsJohnGalt;

Why use strict mode?

You should not think of strict mode as a restriction to write JS code. The purpose is more being a guide to the best way to do things so that the JS engine has the best chance of optimizing and efficiently running the code.

As most JS programs are written in developer teams, strict mode helps collaboration on code and avoids mistakes that slip by in sloppy mode. For example strict mode makes it impossible to accidentally create global variables.

'use strict';

let globalVariable = 'Who is John Galt?';

globalVarible = 'I am John Galt.';

// this will throw a ReferenceError because of the typo
// without 'use strict'; this would create a new variable globalVarible

So strict mode is like a linter reminding you how JS should be written to have the highest quality and best chance at performance.

Examples

Let's look on some examples on what strict mode does not allow (list is not complete).

Using a variable or object without declaring it:

'use strict';

// variable
x = 10;  

// object
y = { key: 'value' };

// both would cause an error

Duplicating a parameter name is not allowed:

'use strict';

function x(p1, p1) {};   

// will cause an error

Octal numeric literals and escape characters are not allowed:

'use strict';

let x = 010;

let y = '\010';

// both would cause an error

Deleting an undeletable property is not allowed:

'use strict';

delete Object.prototype;

// will cause an error

Deleting a variable (or object) is not allowed:

'use strict';

let x = 30;

delete x;

// will cause an error

Writing to a read-only property is not allowed:

'use strict';

let obj = {};

Object.defineProperty(obj, "x", { value: 0, writable: false });

obj.x = 3.14;            

// will cause an error

There are some more cases that strict mode does not allow. For more examples and more details visit the MDN web docs.

Strict mode as default?

If strict mode is strongly recommended why is it not set to default for JS is a question that could come up. The answer is the backwards compatibility of JS. That means that code which once was accepted as valid JS, there will not be a future change to the language that causes that code to become invalid JS.

Think again of the examples shown above. If a JS engine update started assuming code was strict mode even if it's not marked as such and for example you used variables without declaring them, this may cause that the code would break as a result of strict mode controls.

Conclusion

Along with tooling like linters, strict mode is an other important piece for writing clean and and more "secure" JS. You should definitely use strict node in your code. If your code is not written in strict mode you should think about a transition into strict mode. This article gives you some guidance on this topic.

Happy coding!

IIFE... Excuse me, what?

guennithegun — Sat, 07 Dec 2019 21:47:03 +0000

Since the first time I read about IIFE, I could not forget this abbreviation. Iffy...

IIFE stands for immediately invoked function expression. It is a JavaScript function that runs as soon as it is defined. It is a design pattern which is also known as a self executing anonymous function.

The syntax looks like this:

  // IIFE
  (function(){
    // do something here
  })();

So what do we have here? Let's go into details. The IIFE contains two major parts.

anonymous function

The first part is the anonymous function with lexical scope:

  // I am anonymous
  function(){
    // do something here
  };

Hold on a minute what is lexical scope? Check this article for some details on that topic: I would try to explain lexical scope in plain English. Wish me luck.

An anonymous function is a function that was declared without any named identifier to refer to it. It is usually not accessible after its initial creation.

  // normal function definition
  function hello() {
    console.log('A is A');
  };

  hello(); // output 'A is A'

  // anonymous function definition
  function(){
    // do something
  });

A common use for anonymous functions is for example as argument to another function.

  // example
  setTimeout(function() {
    alert('I am John Galt.');
  }, 1000);

In the IIFE the anonymous function is enclosed within the grouping operator ().

direct interpretation of the function

The second part creates the immediately invoked function expression () through which the JavaScript engine will directly interpret the function. The difference to the normal function definition is that with IIFE, declaration and execution are performed at the same time. With the normal function definition you first declare the function and then call it, placing the parentheses after it to indicate that you want to execute it.

why use IIFE?

Ok, so now we know a bit more about the syntax. But what is the benefit of IIFE?

It is about scope. In JavaScript variables declared outside of a function are global variables. Functions declared inside of a function are called local variables.

A global variable can be accessed from anywhere in your code. This comes with some downsides like

you can (accidentally) access the global state, which leads to impure functions
you can overwrite other global variables

Imagine you have two JavaScript files and each contains var johnGalt = {}; The variable johnGalt would be global and therefore shared in all code and executed no matter in which file it was written.

To prevent this the IIFE pattern exists. When you wrap all your global variables into IIFE you take them their globalness. You can treat them as local variables within the IIFE as they are wrapped into a function. The variables within the expression can not be accessed from outside.

  (function() {
    var johnGalt = 'Who is';
  })();

  // variable can not be accessed
  console.log(johnGalt); // Uncaught ReferenceError: johnGalt is not defined

When you need access to the global variables inside the IIFE you can do something like this:

  var galtsGulch = (function() {
    var johnGalt = 'Who is';
    return johnGalt;
  })();

  console.log(galtsGulch); // output 'Who is'

If you assign the IIFE to a variable it does not store the function definition but its return value. So everything which is returned by the IIFE function is accessible from outside. This allows you to control what should be globally accessible and what should not.

You can also do some cool stuff and manipulate your global variables inside IIFE. You can do that like this:

  var galtsGulch = (function() {
    var residents = []; // empty array

    return {
      // add a resident
      add: function(resident) {
        residents.push(resident);
      },
      // get all residents
      getAll: function() {
        return residents;
      }
    };
  })();

  console.log(galtsGulch.getAll()); // []
  galtsGulch.add({ name: 'John Galt' });
  console.log(galtsGulch.getAll()); // [ Object { name: 'John Galt' } ]

Here the IIFE returns an object with the two keys add and getAll. So whenever you access galtsGulch it represents an object with these two keys. The two keys hold functions that allow you to interact with the residents variable from outside. add adds a resident to the array and getAll gets the complete 'residents' variable.

COOL!

conclusion

With the IIFE pattern it is nearly impossible to accidentally modify or access the shared state. That’s why this pattern is so useful, why it’s commonly used in many applications, and why you should use it, too!