ApexSQL Clean has, among others, a useful feature that most people are not even aware of. It provides a client SQL code analysis in C#, Delphi, VB.NET, XAML, XML, ASP.NET, HTML, CSS code etc., and detects which SQL objects are actually being used and which ones aren’t in the referenced database. The SQL code analysis is performed by inspecting the code file for objects in the SQL database. This feature helps keeping SQL databases clean and organized
Many development teams have the need for a quick and easy but effective solution to committing SQL Server database objects to source control, but aren’t yet ready to move to full source control integration at check in/check out level.
In order to get objects under a source control in a “Poor man’s” approach, creation scripts need to be produced for each table, stored procedure, and any other object in a database. Afterwards, the scripts need to be committed to a source control system.
When recovering from a SQL Server database failure, a database administrator needs to restore a set of SQL Server database backups in a logically correct and meaningful restore sequence. With this in mind, to the goal is to devise a disaster recovery strategy by creating a solid backup plan, as well as a proper database restore plan in SQL Server. This article will describe 2 different solutions for creating and scheduling a database restore in SQL Server.
To prevent accidental data loss, it is always good to ensure that there is a disaster recovery solution available. This can be easily achieved by having a standby copy of a primary database on another SQL Server instance, which can be achieved via log shipping.
SQL Server Log shipping is a solution that provides disaster recovery protection at the database level. A log shipping configuration includes one primary server, hosting a live database, and one or more secondary servers that host database copies. The process is fairly simple – a database is backed up and restored from a primary server to the secondary server(s). At regularly scheduled intervals, a transaction log backup and restore is performed at the primary and secondary servers to keep the databases in sync.
A SQL Server database can have stored procedures, tables, defaults, views etc. that aren’t being used anymore, and unless you determine which of your objects are truly unreferenced you will be stuck with them, or risk breaking your database if you delete a wrong object. This is where ApexSQL Clean can help. ApexSQL Clean’s main features are already described in SQL code analysis – full body scan of a SQL database, but here we would like to point out and present one more useful feature: creating a sql database cleanup report. In order to have a complete database cleanup report and dependencies analysis procedure, ApexSQL Clean has a reporting mechanism, which allows keeping track of selected objects and their dependencies.
It is not a rare case that a DBA inherits SQL Server databases with many unused SQL objects. By using ApexSQL Clean, it is easy to clean a SQL database from these unneeded objects and prevent extra objects from making an impact on development by slowing it down and increasing the maintenance workload (e.g. all unused objects still have to have their permissions set, be conformant with coding standards, etc.)
ApexSQL Clean can help determine all dependencies in a SQL database; it also analyzes the impact of potential changes and deletions on SQL database, and determines object interrelationships within the database, between different databases, SQL scripts and even applications
Whenever building a SQL Server database, it must determine which objects to include in it. ApexSQL Build provides a detailed object analysis for building a database or for a database update deployment, with an ability to customize the SQL database objects and include dependent objects automatically. Selecting objects is easy and allows us to easily customize SQL database objects
When comparing live database or database backups using ApexSQL Data Diff, tables with the same name are compared automatically. But what happens with tables and columns with different names when compare SQL tables for differences?
By default, they are excluded from the comparison process and need to be mapped manually using the Object mapping feature. This feature also allows changing tables paired by default, i.e. unmapping them and creating customized comparison pairs. This can be helpful in scenarios where the same tables are differently named in the development and the production database, and data needs to be pushed from the development database to the production one.
A database is one of the most important parts of every information system and therefore is an often target of hackers. Encryption is the process of obfuscating data with the use of a key and/or password making the data unintelligible to anyone without a corresponding decryption key or a password.