Introduction to AbaPerls

Contents:
   Background
   Feature Overview
      SQL Development
      Building and Updating Databases
      A Module-Based Database
      Preparing Pre-Loaded Tables
      Search and Replace in Version-Control
      Other SQL Utilities
      Tools for Sybase PowerDesigner
      Version-control tools
      AbaPerls System Tables
      Supported Platforms
   Getting Started with AbaPerls
      The Find/Replace Track
      The Plain-Developer Track
      The DBA/Configuration-Manager Track
   Limitations and Restrictions
      General Restrictions
      AbaPerls and Unicode
      Quoted Identifiers
   Credits
   License
   Contact Information

Background

AbaPerls is a collection of tools written in Perl that started its life in 1996 to support the development and deployment of the a product known as AbaSec that I worked with at the time – and still do for that matter.

The main focus for AbaPerls is development, configuration-management and installation of MS SQL Server databases that are maintained in a version-control system. The supported version-control systems are Team Foundation Server and Visual SourceSafe. AbaPerls also includes tools for searching and replacing in version-control that are useful for any user, even if you do not use SQL Server. While designed with the aim to support the development of a specific product, AbaPerls is not hard-wired to AbaSec, but can be used for other development efforts for SQL Server. AbaPerls aims to be a product, but it will have to be admitted that there are some rough edges in that regard. It was designed as an in-house development tool, with the toolsmith in reach. A primary aim in the development of AbaPerls has always been to keep down development time, the development time of AbaPerls that is. So in places AbaPerls makes assumptions or imposes limitations that fit well with how we work with AbaSec, but may appear utterly confusing or inconvenient to you. (Hey, even my colleagues thought some of it was funny. They got used to it...)

And just a word of warning if you are expecting nice-looking Windows dialogues: The AbaPerls tools are all command-line tools only. There is no GUI.

AbaSec developers should be aware of that AbaPerls very much is a moving target, and tools are changed or added every now and then.

Feature Overview

SQL Development

The prime developer component of AbaPerls is the load tool ABASQL. ABASQL is a wrapper on the AbaPerls file-loading process, which goes far beyond what you get through SQL Server Management Studio. Here is a sample of what you get:

Typically you invoke ABASQL from a external text editor that permits you execute a command-line tool from the editor. In the AbaSec group we use TextPad and Visual Studio.

Building and Updating Databases

To build an empty database AbaPerls provides the tool DBBUILD. DBBUILD finds the SQL files in a number of version-control directories and loads the files into database in a well-defined order using the AbaPerls file-loading process. That is, everything you get with ABASQL, you get with DBBUILD. Since the log from a database build can become huge, AbaPerls offers LISTERRS that extracts the interesting part of the log, that is, the errors and warnings.

DBUPDGEN is a tool that compares two labels for a directory tree in the version-control system, and from the differences it generates an update script, that will update the database from one label to the other. These upgrade scripts use the AbaPerls file-loading process, so again the full power of ABASQL is available.

AbaPerls is strict on mapping object types to certain file extensions, so that table definitions are in .tbl files, stored procedures in .sp files and so on. AbaPerls is also strict that the name of the file must match the name of the object. Furthermore, there is the AbaPerls SQL directory structure, which says that a certain file extension should be in a certain directory.

A Module-Based Database

The product I work with consists of several modules, some large and some small, and each costumer typically has their configuration. Unless there is some special reason, all modules reside in the same database, as high-level modules typically refer to tables and stored procedures in the base modules.

These modules are in AbaPerls called subsystems. A subsystem is set of database objects – types, tables, stored procedures etc – that you build or update together. A database can consist of one or more subsystems. You define your system (which can be spread over several databases) in a system-definition file (or sysdef-file for short) which lists your subsystems and where they are located in version-control. You define the subsystem configuration for a specific database in a configuration file (or config-file for short) which defines which subsystems that are to be included in a specific database. The config-file typically inherits from the sysdef-file and adds configuration options, either on database level or on subsystem level.

Provided that you include the ABAPERLS subsystem, which is the database part of AbaPerls and includes the AbaPerls system tables in the database, DBBUILD saves the configuration options in the database. This permits ABASQL and the update scripts generated by DBUPDGEN to act as if these options had been specified on the command line. For instance, in the config-file you can specify that all stored procedures, triggers and views are to be obfuscated, whereupon ABASQL will automatically add WITH ENCRYPTION when it loads the objects.

DBUPDGEN can also work with a config-file and generate an update script for many subsystems. When you run the update script, it checks the database for available subsystems, and ignores the subsystems in the script not present in the database.

Sometimes you may want to see what a config-file maps to. To this end there is the tool LISTCONFIG.

Preparing Pre-Loaded Tables

In many databases, there are tables into which you need load with data, before the application can start working. AbaPerls includes the tool INSFILGEN which reads an Excel workbook and from this generates an INSERT-file.

Search and Replace in Version-Control

AbaPerls includes two tools to search and make automatic edits for files under version control, be that TFS or SourceSafe:

Other SQL Utilities

Tools for Sybase PowerDesigner

Version-control tools

These tools are used to enforce AbaPerls's label rules in the version control system, and they are not very useful on their own.

AbaPerls System Tables

AbaPerls has its own set of tables to keep track of versions of subsystems and objects loaded in the database. These tables, and the stored procedures that goes with them, constitute a subsystem of its own, called ABAPERLS. The use of these tables is not mandatory; you need to explicitly include the ABAPERLS subsystem in your database to make use of them. But without them, you will be not be using the full power of AbaPerls. For instance, in a database which has the ABAPERLS subsystem installed, you can use the stored procedure ap_sob_report_suspects_sp to see if anyone has loaded files outside the regular installation scripts. 

Supported Platforms

AbaPerls runs on Windows and supports SQL Server 2000 and later, Visual SourceSafe 2005 and Team Foundation Server 2010. You need Perl 5.12 to run AbaPerls, but Perl is free software. For further information, see Downloading and installing AbaPerls.

Getting Started with AbaPerls

Over the years, more and more features and concepts have been added to AbaPerls, so it does take more than a coffee break to learn it. The good news is that you don't have to learn everything to start using some of the AbaPerls tools. Here I try to outline three different "tracks" to get started with AbaPerls.

The Find/Replace Track

The tools SSGREP and SSREPLACE are powerful enough to themselves be interest for shops that do not use MS SQL Server, or are not interested in the developer and CM support offered by AbaPerls but who use SourceSafe or Team Foundation Server. For this track you may want to read:

  1. Downloading and installing AbaPerls. You only need to read this, if AbaPerls is not already available at your site.
  2. Running AbaPerls on your machine, so that you can setup AbaPerls to run on your machine.
  3. The command descriptions for SSGREP and SSREPLACE.
  4. Version-control concepts, the section on VC-paths only.
  5. Sysdef-files and Config-files, if you want to be able to search/replace in more than one hierarchy at the same time. You mainly need to read the part about config-files and when you come to the section The Version Specification, you can stop or take a brief look at the examples at the end of that page.

The Plain-Developer Track

This track is for SQL developers who write stored procedures and such, but do not build or update databases. They will in many cases use only ABASQL. Occasionally they may use SSGREP, SSREPLACE, INSFILGEN and RUNSPS.

The recommended documents for this track are:

  1. Downloading and installing AbaPerls. You only need to read this, if AbaPerls is not already available at your site.
  2. Running AbaPerls on your machine, so that you can setup AbaPerls to run on your machine.
  3. The AbaPerls subsystem structure, particularly the second part, The AbaPerls SQL directory structure.
  4. How AbaPerls loads a file, to understand what ABASQL does behind your back.
  5. The command description for ABASQL.
  6. Using ABASQL with TextPad or Visual Studio so you can learn to use ABASQL from your text editor.

This far, you are ready to use ABASQL. Later on, you may also want to read these documents:

  1. The Preppis preprocessor, if you want to use the power of this tool.
  2. Learn about Object Checking, so that you understand what extra checks of your code that ABASQL performs.
  3. Read about RUNSPS, so you know about this tool when you need to test.
  4. SSGREP and SSREPLACE, see also the Find/Replace track above.
  5. You can defer reading about INSFILGEN until you actually need to use it.
  6. Read the CLR page, to learn how to use the CLR page with AbaPerls.
  7. If you want to grant permissions through stored procedures beyond ownership chaining, read the page Modules with Special Permissions.

The DBA/Configuration-Manager Track

This track includes the full set of AbaPerls tools and concepts. Even a DBA or a CM person should probably start with the plain-developer track, and play a little with ABASQL before moving on.

Here is a complete suggestion of a reading order for a DBA or a CM-person which mainly goes into topics first, before arriving at the command descriptions.

  1. Downloading and installing AbaPerls.
  2. Running AbaPerls on your machine.
  3. The AbaPerls subsystem structure, to learn how AbaPerls look at subsystems and versions, and how AbaPerls maps SQL files into the AbaPerls SQL directory structure.
  4. Version-control concepts, to learn about the general model AbaPerls applies for version-control systems.
  5. Depending on which version-control system you use, read Notes on SourceSafe or Notes on Team Foundation Server.
  6. Sysdef-files and Config-files and Configuration options. Even if you don't plan to divide your database in subsystems, you still need to grasp the subsystem concept and the configuration options.
  7. The command LISTCONFIG, so that you can play with configuration files.
  8. How AbaPerls loads a file, to understand what AbaPerls is doing behind your back with the SQL code you feed it.
  9. Learn about Object Checking, so that you understand what extra checks of your code that ABASQL performs.
  10. The command description for ABASQL, so that you can start playing with single files.
  11. Using ABASQL with TextPad or Visual Studio, so you can use ABASQL from your text editor.
  12. The command descriptions for SSGREP and SSREPLACE.

This far, this is mainly an extended developer track. We now move to more central topics for a DBA/CM-person.

  1. The life-cycle of a database, to get an overview on how to use DBBUILD and the update scripts generated by DBUPDGEN.
  2. The command descriptions for DBBUILD and LISTERRS. This may be a good point for composing a sample structure, or simply build a database with the ABAPERLS subsystem only.
  3. Installation at a customer site, the parts that apply to DBBUILD.
  4. You need to give The Preppis preprocessor at least a cursory glance since INSFILGEN uses Preppis.
  5. The command description for INSFILGEN, as must for a DBA who prepares INSERT-files. (A strict CM-person may read this more cursory.)
  6. DOBCP and TBLCNT to move data.
  7. The command description for DBUPDGEN. Many readers will be interested to read this directly after DBBUILD, and that's alright. I've deferred it a bit in the reading list, as this is by far the longest document in the set, and the tool is also the most complex of them all – but it is powerful!
  8. Installation at a customer site, to read the parts on update scripts generated by DBUPDGEN and repeat the parts on DBBUILD.
  9. Browse the documentation of the AbaPerls system tables. Pay particular interest to the table abasysobjects and the stored procedure ap_sob_report_suspects_sp (with which you can trace objects that somehow has not been loaded the "proper" way) and ap_zz_sob_load_sp (with you can initialize abasysobjects if in you install AbaPerls in an existing database.

As for the remaining commands and topics, I have not listed them in any reading-order; explore them at your own pace.

Limitations and Restrictions

This section makes an attempt to list resitrctions with AbaPerls, that is unsupported features etc. It is not likely to be complete. When it doubt, test to see if it works or not.

General Restrictions

There are many features in SQL Server for which AbaPerls does not have any direct support. For some object types that does not have a dedicate file type, like users, certificates etc, you can easily work around this by defining them in .sql or .postsql files. In fact that is more or less the intention. For other features, you are more or less tied to what AbaPerls supports. Here is a list of such hard restrictions, not likely to be exhaustive:

Since AbaPerls aims at building and maintaining a database, there is not much support for server-level objects like extended events. Rather AbaPerls stays away from the server level, with the exception of creating keys and logins to grant modules server-level permission.

Also beware that AbaPerls may be sensitive to formatting or be confused by what is actually legal syntax, as discussed in the section Pre-SQL Analysis: Creating and recreating objects on the file-load page.

AbaPerls and Unicode

Generally AbaPerls supports Unicode for the contents of files as well as the in the names of tiles and objects. However, observe the following.

Quoted Identifiers

AbaPerls makes a half-hearted attempt to support identifiers quoted with "" or [], but more work needs to be done before AbaPerls can be said to fully support this. One known restriction is that names including a single quote, e.g. [Jane's table] do not work and yields an error message Overall, testing has not been extensive in this area.

Note also that by default, AbaPerls replaces all occurrences of double quotes as string delimiter with single quotes, so if you wish to use double quotes to delimit identifiers (which is ANSI compatible in difference to [] which is SQL Server-specific), you must use the configuration option ‑noquoterepl

Credits

Through the years, several of my co-workers have provided valuable input and ideas, and I particularly like to mention Leif Jettman and Jan Afrell who have suffered from bugs due to quick check-ins, less ideal design decisions etc.

And of course, due credit should go to Larry Wall who originally designed Perl. Without this powerful language AbaPerls would never have come into existence. I would also like to thank Jan Dubois who wrote Win32::OLE without which the connection to SourceSafe would not have been possible and Toshiyuki Yamato who wrote Win32::CLR that made the connection to TFS possible.

License

Perl is free software, available under the Perl Artistic Licensce.

Contact Information

Erland Sommarskog, esquel@sommarskog.se.