In this article, we’ll look at how to use dbForge Data Pump and the PowerShell command line to bulk transfer data from MS Access tables to SQL Server.

Manual data entry may take a long time when moving large datasets. Instead, bulk data import is preferable because it minimizes the possibility of data entry errors while quickly transferring data between sources without requiring manual entry of every record.

To maintain regular data synchronization and keep data current, you can also automate and schedule bulk data import. You can transfer data between tables in a variety of formats using data import.

As you can see, using bulk data import has a lot of advantages. The BCP utility and a SQL Bulk Insert statement are where we begin our quick look at how it can be implemented.

SQL BULK INSERT vs BCP utility

Large amounts of data can be inserted from an external file into a SQL Server table or view using the BULK INSERT statement. It is appropriate for situations in which data loading effectiveness and efficiency are crucial.

The syntax of the claim is as follows:

BULK INSERT table_name
FROM 'path_to_file'
WITH (options);

where:

• table_name is the name of the table into which the data will be inserted. The name should be specified in the following format – database_name.schema_name.table_name.
• path_to_file is the full path to the file with the data you want to import.
• options are various options or configurations for the bulk insert operation.

Using the bcp command-line tool is another well-liked method for bulk data import. Bulk Copy Program is known as BCP. Users can quickly import and export data from files into tables and views on SQL Server.

High-performance data transfer is the aim of BCP. It is frequently used for data migration, data warehousing, and ETL (Extract, Transform, Load) processes because it can effectively handle large datasets. To customize the import or export process to your needs, BCP lets you specify a variety of options, including data format, field and row terminators, and authentication details.

The following is an illustration of a BCP command that imports data from a CSV file into a SQL Server database table:

bcp MyDatabase.dbo.MyTable in datafile.csv -c -T ','

where:

• MyDatabase.dbo.MyTable is the target table into which data should be imported. In this illustration, data is being imported into the “MyTable” table, which is part of the “dbo” schema of the “MyDatabase.”
• in identifies an import operation, or the copying of data from an external file into the specified table, as being in progress.
• datafile.csv is a CSV file that you want to import data from on the outside.
• -c demonstrates that you are importing using character data format. CSV files and other text-based data sources are imported using it.
• -T ',' is the field terminator used in the CSV file. In this case, it’s a comma (,), which is common for CSV files. This parameter tells BCP how to recognize the boundaries between fields in the CSV data.

The BULK INSERT and BCP methods both handle bulk data operations, but they do so in different ways. Let’s examine their parallels and discrepancies.

Similarities:

• Efficient transfer of large volumes of data into SQL Server tables.
• Optimized for high-performance data loading.
• Support for data import from external sources into SQL Server tables.

Differences:

• A command-line tool called BCP is used to import and export data into SQL Server.
  A Transact-SQL statement executed by SQL Server is called BULK INSERT. It is limited to data import.
• Database administrators and developers who are comfortable using command-line tools can use BCP. As a result, additional setup and configurations might be needed.
  For SQL Server users and database developers who are accustomed to writing SQL queries, BULK INSERT is more convenient.
• Security issues may arise if BCP asks for login information and passwords to be passed as command-line arguments.
  When using the SQL Server login, BULK INSERT can be more secure, especially when combined with security features built into the SQL Server database.

Introduction to Data Pump

DbForge Data Pump for SQL Server is your go-to option when you need to easily and quickly export/import data from external files to SQL Server databases. It is a powerful and adaptable SQL Server Management Studio data migration add-in for transferring data between different database systems and populating databases with data from external sources, regardless of their formats or structures. The tool supports the export and import of data in popular formats like Excel, CSV, XML, JSON, Text, MS Access, etc. Additionally, you can use a template file that has the same settings that apply to export/import operations to handle repetitive situations.

Let’s use dbForge Data Pump to import data from MS Access tables to brand-new SQL Server tables.

Retrieving all tables from an MS Access database

Make the Microsoft Access file with the data that will be imported into SQL Server tables first. First, run the following SELECT statement to get a list of all tables from an MS Access database:

SELECT name FROM MSysObjects WHERE type = 4

where:

• name specifies the “name” column from the “MSysObjects” table that you want to retrieve. Query names as well as those of other database objects are typically stored in the “name” column.
• MSysObjects is a Microsoft Access system table that contains data on various database objects.
• type = 4 indicates a filtering condition for the results. A “type” with the value 4 typically refers to tables or saved queries in Microsoft Access. Consequently, the query instructs the database to only choose rows where the “MSysObjects” table’s “type” column equals 4.

Once finished, save a file with the extension.accdb.

Proceed to using dbForge Data Pump to import data after that.

Let’s make sure the tables that will receive the data import are empty. Open SSMS and run the SELECT statements to retrieve the data to accomplish this.

As you can see, the tables are currently empty, so we can move on to filling them with data.

Create a template to import settings

To make things simple, we’ll use the Data Import wizard in dbForge Data Pump to create a template with predefined import settings. By removing the need to manually configure import settings for each import operation, templates save time and effort. You can reuse a template with the desired settings rather than starting from scratch, which streamlines the import procedure and lowers the possibility of human error.

To facilitate data transfer between Microsoft Access files and non-Microsoft Office applications to other data sources like Microsoft SQL Server, download and install Microsoft Access Database Engine beforehand. If not, the Import wizard will display the following error:

Once all the necessary steps have been taken, right-click the required database in SSMS Object Explorer and choose Data Pump > Import Data to launch the Data Import Wizard.

Select an.mdb format in the wizard and the source file from which data will be imported before clicking Next.

Choose a database, a table to import data to, a source table, and a target connection on the destination page. Next, select Next.

The Data Import wizard opens with the predefined connection parameters of the chosen table if it is launched from Object Explorer.

You can, at your discretion, go through every page of the wizard to enter the necessary details and settings.

To create a template, click Save Template at the bottom of the wizard, enter the name and location of your template, and then click Save. It is advised to keep the template and all related files on your primary D: hard drive for proper operation.

Done! The template is ready to use. Now, we can import data in bulk with the PowerShell script.

Automating bulk data import

The PowerShell script is made up of a series of commands that PowerShell is told to run in order to carry out various tasks.

Let’s write a PowerShell script that details every action it takes to import data in bulk.

1. Open the Windows Integrated Scripting Environment (ISE) console for PowerShell.

2. Click New Script on the toolbar and type the following guidelines:

# Define the path to the Microsoft Access database
$dbPath = "D:\og.accdb"

# Path to your DBForge
$diffToolLocation = "C:\Program Files\Devart\dbForge SQL Tools Professional\dbForge Data Pump for SQL Server\datapump.com"

# Define the provider and the data source
$connectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=`"$dbPath`";"

# Create a new OleDb connection
$connection = New-Object System.Data.OleDb.OleDbConnection($connectionString)

# Open the connection
$connection.Open()

# Get the schema information for the data source
$tables = $connection.GetSchema('Tables')

# Filter out system tables to get only user tables
$userTables = $tables | Where-Object { $_.TABLE_TYPE -eq 'TABLE' -and $_.TABLE_NAME -notlike 'MSys*' }

# Process each table
$userTables | ForEach-Object {
    $tableName = $_.TABLE_NAME
    Write-Output "Processing table: $tableName"
    
    #Command-line string for importing data into your SQL Server database
    $process = Start-Process -FilePath $diffToolLocation -ArgumentList "/dataimport /templatefile:`"D:\imptemplate.dit`" /connection:`"Data Source=<server_name>;Integrated Security=True;User ID=<username>`" /inputfile:`"D:\og.accdb`" /inputtable:$tableName /table:`"Olympic_Games_Dev.dbo.$tableName`" /errormode:abort" #-PassThru -Wait -windowstyle hidden         
    
    #If you need to process the tables one by one to reduce server load - uncomment it.
    #Start-Sleep -Seconds 10                        
                            }

# Close the connection
$connection.Close()

3. Substitute the following arguments with your relevant data:

• $dbPath: The source MS Access file’s path, from which data should be imported.
• $diffToolLocation: The location of the dbForge Data Pump installation folder.
• $connectionString: Microsoft Access databases in the.accdb file format can be interacted with using the OLE DB Provider.
• /templatefile: How to get to the template.you used the Data Import wizard to create the dit file.
• /connection: Connection specifications for the target database tables that you want to import data into.
• /inputfile: Name of the source file that should be used to import data.
• /table: Full name of the target SQL Server table, including the database and associated schema, for instance, Olympic_Games_Dev.dbo.$tableName.

Due to the fact that we declared the variable $tableName, all tables present in the database will be processed without your having to manually enter their names. This will streamline the procedure and lower the likelihood of errors.

After the script has been written, you can run it by selecting Run Script from the toolbar.

Done! Return to dbForge Data Pump at this time to confirm that the data has been moved from MS Access to the SQL Server database tables. Execute the SELECT statements to achieve this.

The result shows the tables that have been filled with information.

Conclusion

In conclusion, bulk data import is a crucial task in database administrators’ day-to-day responsibilities. In this article, we reviewed the procedures for transferring data between databases, specifically how to import Microsoft Access data into SQL Server. Additionally, we have shown how to use the PowerShell ISE script and dbForge Data Pump to import data in bulk. Making a template, updating the script’s arguments with your actual data, and running the script are all that are required.

There is a fairly easy way to eliminate this problem, and that is to use the ChangeDatabase method on the Connection object.

Our web application was connecting to one of fifty different databases that all reside on the same instance of SQL Server. Each of our clients has their own database. But our application was creating fifty different connection pools. We were able to have all the clients share a single pool of connections by first connecting to a neutral database, then redirecting the connection to the desired database.

We created a new database on the server, called Central, then we had all the connections to the database first connect to Central as the Initial Catalog. The next step was to call ChangeDatabase to switch to the desired database. This technique did not create a new connection to SQL Server and did not create a new connection pool on the .Net client. Microsoft documentation mentions this technique here: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling#pool-fragmentation-due-to-many-databases , but their example code does not show the ChangeDatabase method, which is more efficient than their example.

In a nutshell, you can do this:

connection.Open();
connection.ChangeDatabase(“Client1”);

I created a simple Windows Form App to test the idea.  The test app runs a query to return the name of the current database it is in.  Also, on the SQL Server I run a query to see all the connections that exist.  Doing this I was able to prove that using ChangeDatabase did not create a new connection to SQL Server and my .Net SQL Connection Object was pointing at the correct desired database.  Sample code, query, and output is below:

Sample C# .Net Forms App:

using System;
using System.Data.SqlClient;
using System.Windows.Forms;
 
namespace SQLConnectionTest
{
    public partial class Form1 : Form
    {
        //https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling#pool-fragmentation-due-to-many-databases
        private void button1_Click(object sender, EventArgs e)
        {
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=master;Trusted_Connection = yes"))
            {
                connection.Open();
                RunSQL(connection, "select DB_NAME()");
            }
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=model;Trusted_Connection = yes"))
            {
                connection.Open();
                RunSQL(connection, "select DB_NAME()");
            }
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=msdb;Trusted_Connection = yes"))
            {
                connection.Open();
                RunSQL(connection, "select DB_NAME()");
            }
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=master;Trusted_Connection = yes"))
            {
                connection.Open();
                RunSQL(connection, "select DB_NAME()");
            }
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=master;Trusted_Connection = yes"))
            { 
                connection.Open();
                connection.ChangeDatabase("TempDb");
                RunSQL(connection, "select DB_NAME()");
            }
 
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=master;Trusted_Connection = yes"))
            {
                connection.Open();
                RunSQL(connection, "select DB_NAME()");
            }
            using (SqlConnection connection = new SqlConnection(@"Server=.\;Database=master;Trusted_Connection = yes"))
            {
                connection.Open();
                connection.ChangeDatabase("TempDb");
                RunSQL(connection, "select DB_NAME()");
                connection.ChangeDatabase("model");
                RunSQL(connection, "select DB_NAME()");
            }
        }
 
        public static void RunSQL(SqlConnection connection, string queryString)
        {
            SqlCommand command = new SqlCommand(queryString, connection);
            try
            {
                SqlDataReader reader = command.ExecuteReader(); 
                if (reader != null)
                {
                    while (reader.Read())
                    {
                        Console.WriteLine("\t{0}", reader[0]);
                    }
                    reader.Close();
                }
            }
            catch (Exception ex){Console.WriteLine(ex.Message);}
        }
        public Form1()
        {
            InitializeComponent();
        }
 
 
    }
}

Output from Running the App written to console:

master
model
msdb
master
tempdb
master
tempdb
model

Query to see connections on SQL Server:

CREATE TABLE #TmpLog
(SPID int, Status VARCHAR(150), Login varchar(100), HostName VARCHAR(150), BlkBy varchar(30), DBName varchar(60), Command varchar(500),
CPUTime int, DiskIO int, LastBatch varchar(20), ProgramName varchar(200), SPID2 int, requestid int)
INSERT INTO #TmpLog
EXEC sp_who2
SELECT SPID, Status, Login, HostName, BlkBy, DBName, Command, ProgramName
FROM #TmpLog
where STATUS not in (‘BACKGROUND’) and Command not in (‘TASK MANAGER’) and ProgramName like ‘.net%’
DROP TABLE #TmpLog
go

Results of running query on SQL Server:

We’ll start with an example .NET 6 CRUD API from a tutorial I posted recently, it uses the EF Core InMemory db provider by default for testing, we’ll update it to connect to a SQL Server database and run EF Core migrations to auto generate the database and tables from code. 

Requirements!

To follow the steps in this tutorial you’ll need the following:

• .NET SDK – includes the .NET runtime and command line tools.
• Visual Studio Code – code editor that runs on Windows, Mac and Linux. If you have a different preferred code editor that’s fine too.
• C# extension for Visual Studio Code – adds support to VS Code for developing .NET applications.
• SQL Server – you’ll need access to running SQL Server instance for the API to connect to, it can be remote (e.g. Azure, AWS etc) or on your local machine. The Express edition of SQL Server is available for free at https://www.microsoft.com/sql-server/sql-server-downloads.

Download & Run the example .NET 6 API

Follow these steps to download and run the .NET 6 CRUD API on your local machine with the default EF Core InMemory database:

1. Download or clone the tutorial project code from https://github.com/cornflourblue/dotnet-6-crud-api
2. Start the api by running dotnet run from the command line in the project root folder (where the WebApi.csproj file is located), you should see the message Now listening on: http://localhost:4000.
3. You can test the API directly with a tool such as Postman.

Starting in debug mode

You can also start the application in debug mode in VS Code by opening the project root folder in VS Code and pressing F5 or by selecting Debug -> Start Debugging from the top menu, running in debug mode allows you to attach breakpoints to pause execution and step through the application code.

Update .NET 6 API to use SQL Server

Add SQL Server database provider from NuGet

Run the following command from the project root folder to install the EF Core database provider for SQL Server from NuGet:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

Add connection string to app settings

Open the appsettings.json file and add the entry "ConnectionStrings" with a child entry for the SQL Server connection string (e.g. "WebApiDatabase"), the connection string should be in the format "Data Source=[DB SERVER URL]; Initial Catalog=[DB NAME]; User Id=[USERNAME]; Password=[PASSWORD]", or to connect with the same account that is running the .NET API use the connection string format "Data Source=[DB SERVER URL]; Initial Catalog=[DB NAME]; Integrated Security=true".

When EF Core migrations generates the database, the Initial Catalog value will be the name of the database created in SQL Server.

The updated appsettings.json file with the connection string should look something like this:

{
    "ConnectionStrings": {
        "WebApiDatabase": "Data Source=localhost; Initial Catalog=dotnet-6-crud-api; User Id=testUser; Password=testPass123"
    },
    "Logging": {
        "LogLevel": {
            "Default": "Information",
            "Microsoft.AspNetCore": "Warning"
        }
    }
}

Update Data Context to Use SQL Server

The DataContext class located at /Helpers/DataContext.cs is used for accessing application data through Entity Framework. It derives from the Entity Framework DbContext class and has a public Users property for accessing and managing user data.

Update the OnConfiguring() method to connect to SQL Server instead of an in memory database by replacing options.UseInMemoryDatabase("TestDb"); with options.UseSqlServer(Configuration.GetConnectionString("WebApiDatabase"));.

The updated DataContext class should look like this:

namespace WebApi.Helpers;

using Microsoft.EntityFrameworkCore;
using WebApi.Entities;

public class DataContext : DbContext
{
    protected readonly IConfiguration Configuration;

    public DataContext(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        // connect to sql server with connection string from app settings
        options.UseSqlServer(Configuration.GetConnectionString("WebApiDatabase"));
    }

    public DbSet<User> Users { get; set; }
}

Create SQL Database from code with EF Core Migrations

Install dotnet ef tools

The .NET Entity Framework Core tools (dotnet ef) are used to generate EF Core migrations, to install the EF Core tools globally run dotnet tool install -g dotnet-ef, or to update run dotnet tool update -g dotnet-ef. For more info on EF Core tools see https://docs.microsoft.com/ef/core/cli/dotnet

Add EF Core Design package from NuGet

Run the following command from the project root folder to install the EF Core design package, it provides cross-platform command line tooling support and is used to generate EF Core migrations:

dotnet add package Microsoft.EntityFrameworkCore.Design

Generate EF Core migrations

Generate new EF Core migration files by running the command dotnet ef migrations add InitialCreate from the project root folder (where the WebApi.csproj file is located), these migrations will create the database and tables for the .NET Core API.

Execute EF Core migrations

Run the command dotnet ef database update from the project root folder to execute the EF Core migrations and create the database and tables in SQL Server.

Check SQL Server and you should now see your database with the tables Users and __EFMigrationsHistory.

Restart .NET 6.0 CRUD API

Stop and restart the API with the command dotnet run from the project root folder, you should see the message Now listening on: http://localhost:4000 and the API should now be connected to SQL Server.

The below steps show how to use a SQLite database in development and a SQL Server database in production, but you could switch these to any database providers you like that are supported by EF Core.

Create Main EF Core DB Context for SQL Server

Create the main DB context class that defines the entities available in the database via public DbSet<TEntity> properties, and configure it to connect to the production database (SQL Server in this case).

Below is the main DB context from the example ASP.NET Core api linked above, it has the class name DataContext and is located in the /Helpers directory of the project, but you can choose any class name and directory you prefer.

using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;
using WebApi.Entities;

namespace WebApi.Helpers
{
    public class DataContext : DbContext
    {
        protected readonly IConfiguration Configuration;

        public DataContext(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        protected override void OnConfiguring(DbContextOptionsBuilder options)
        {
            // connect to sql server database
            options.UseSqlServer(Configuration.GetConnectionString("WebApiDatabase"));
        }

        public DbSet<User> Users { get; set; }
    }
}

Create Development EF Core DB Context for SQLite

Create a development DB context that inherits from the main DB context above and overrides the database provider in the OnConfiguring() method.

Below is the development DB context from the example ASP.NET Core api that overrides the database provider to connect to SQLite instead of SQL Server. Having a second EF Core DB Context that derives from the main DB context is what enables the project to support multiple different database providers.

using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;

namespace WebApi.Helpers
{
    public class SqliteDataContext : DataContext
    {
        public SqliteDataContext(IConfiguration configuration) : base(configuration) { }

        protected override void OnConfiguring(DbContextOptionsBuilder options)
        {
            // connect to sqlite database
            options.UseSqlite(Configuration.GetConnectionString("WebApiDatabase"));
        }
    }
}

Generate SQLite EF Core Migrations

Run the following command to generate EF Core migrations for SQLite and store them in their own folder.

dotnet ef migrations add InitialCreate --context SqliteDataContext --output-dir Migrations/SqliteMigrations

Generate SQL Server EF Core Migrations

Run the following command to generate EF Core migrations for SQL Server and store them in their own folder.

The environment variable ASPNETCORE_ENVIRONMENT needs to be set to Production so the SQL Server DataContext class is configured with the .NET Core dependency injection system, see the ConfigureServices() method below.

Configuring environment variables from the command line is slightly different on MacOS and Windows.

Windows

set ASPNETCORE_ENVIRONMENT=Production
dotnet ef migrations add InitialCreate --context DataContext --output-dir Migrations/SqlServerMigrations

MacOS

ASPNETCORE_ENVIRONMENT=Production dotnet ef migrations add InitialCreate --context DataContext --output-dir Migrations/SqlServerMigrations

Configure Startup.cs to use SQLite in Development and SQL Server in Production

Below is a cut down version of the Startup.cs file from the example ASP.NET Core api that just includes the bits related to the EF Core DB context configuration and automatic database migration.

Lines 23 - 26 configure which type of data context is injected by the .NET Core dependency injection system when a DataContext instance is required by a class. In production an instance of the main DataContext class is used which connects to SQL Server, otherwise (i.e. in development) an instance of the SqliteDataContext is used.

An instance of the DataContext is injected as a parameter into the Configure() method, the data context instance is then used to apply any pending migrations to the database by calling the dataContext.Database.Migrate() method on line 35.

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Hosting;
using WebApi.Helpers;

namespace WebApi
{
    public class Startup
    {
        private readonly IWebHostEnvironment _env;

        public Startup(IWebHostEnvironment env)
        {
            _env = env;
        }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            // use sql server db in production and sqlite db in development
            if (_env.IsProduction())
                services.AddDbContext<DataContext>();
            else
                services.AddDbContext<DataContext, SqliteDataContext>();

            ...
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env, DataContext dataContext)
        {
            // migrate any database changes on startup (includes initial db creation)
            dataContext.Database.Migrate();
            
            ...
        }
    }
}

This article discusses how we can use Serilog to log structured data to a SQL Server database. To work with the code examples provided in this article, you should have Visual Studio 2019 installed in your system.

Create Your First ASP.NET Core 3.0 Project

Make sure you create your ASP.NET Core project in Visual Studio. We assume that you have installed Visual Studio on your computer.

Install the NuGet packages for Serilog

To work with Serilog, you should install the Serilog packages from NuGet. You can do this either via the NuGet package manager inside the Visual Studio 2019 IDE, or by executing the following commands at the NuGet package manager console:

Install-Package Serilog
Install-Package Serilog.AspNetCore
Install-Package Serilog.Sinks.MSSqlServer
Install-Package Serilog.Settings.Configuration

Initialize Serilog in Program.cs in ASP.NET Core

The following code snippet illustrates how you can plug Serilog into ASP.NET Core. Note how the UseSerilog() extension method has been used to set Serilog as the logging provider.

public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                   .UseStartup<Startup>()
                   .UseSerilog()
                   .Build();

Build an example web host in ASP.NET Core

Naturally, we’ll need an application to illustrate the use of Serilog. Here is the complete source code of the Program class for our example app. Note how we’ve configured and built the web host.

    public class Program
    {
        public static void Main(string[] args)
        {
            IConfigurationRoot configuration = new
            ConfigurationBuilder().AddJsonFile("appsettings.json",
            optional: false, reloadOnChange: true).Build();
            Log.Logger = new LoggerConfiguration().ReadFrom.Configuration
            (configuration).CreateLogger();
            BuildWebHost(args).Run();
        }
        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .UseSerilog()
                .Build();
    }

Configure database connection settings in ASP.NET Core

When you create a new ASP.NET Core project in Visual Studio, the appsettings.json file is created by default. Here is where you can specify the database connection string and other configuration information. Open the appsettings.json file from the project we created earlier and enter the following information:

{
  "Serilog": {
    "MinimumLevel": "Information",
    "WriteTo": [
      {
        "Name": "MSSqlServer",
        "Args": {
          "connectionString": "Data Source=LAPTOP-ULJMOJQ5;Initial
           Catalog=Research;    
     User Id=joydip; Password=sa123#;",
          "tableName": "Log",
          "autoCreateSqlTable": true
        }
      }
    ]
  }
}

Create a database table to log data in SQL Server

You might want to create the log table yourself as well. Below is the script you can use to create a log table in the SQL Server database.

CREATE TABLE [Log] (
   [Id] int IDENTITY(1,1) NOT NULL,
   [Message] nvarchar(max) NULL,
   [MessageTemplate] nvarchar(max) NULL,
   [Level] nvarchar(max) NULL,
   [TimeStamp] datetimeoffset(7) NOT NULL,
   [Exception] nvarchar(max) NULL,
   [Properties] nvarchar(max) NULL
   CONSTRAINT [PK_Log]
     PRIMARY KEY CLUSTERED ([Id] ASC)
)

When you run the application, a new table named Log will be created and the ASP.NET Core startup events will be logged there. Figure 1 below shows the data that has been logged inside the Log table.

Log data in action methods in ASP.NET Core

You can leverage dependency injection to inject a logger instance in your controller as shown in the code snippet below:

public class DefaultController : Controller
{
   private readonly ILogger<DefaultController> _logger;
   public DefaultController(ILogger<DefaultController> logger)
   {
      _logger = logger;
   }
}

The following code snippet illustrates how you can take advantage of Serilog in your controller’s action methods to log data.

public class DefaultController : Controller
    {
        private readonly ILogger<DefaultController> _logger;
        public DefaultController(ILogger<DefaultController> logger)
        {
            _logger = logger;
        }
        public IActionResult Index()
        {
            _logger.LogInformation("Hello World");
            return View();
        }
    }

Although independent of .NET Core, Serilog plugs into the ASP.NET Core ecosystem nicely, making structured logging easy and convenient. Serilog also takes advantage of dozens of sinks to send the logs to many different logging targets ranging from text files to databases to hosting providers. I will post other interesting post in next post.