An SQL text by Erland Sommarskog, SQL Server MVP.
AbaPerls is a collection of tools that I started working on 1996 to meet the needs we had when developing and deploying the database that was part of our product. Over the years, AbaPerls grew to be fairly complex and offer many features missing from SQL Server. While AbaPerls was targeted to meet our specific needs, I still thought it had features that were of general interest and I put up AbaPerls on my web site to share with the community. Unfortunately though, I have not been able to keep up with all new features added to SQL Server, but only added support for things when there has been a real need. Furthermore, for AbaPerls to have a future, it would need to support Git, but I can't see that the mindset of AbaPerls fits with the mindset of Git.
Nevertheless, I have decided to keep AbaPerls available for download, but with a deprecation label: I can't recommend that you embrace AbaPerls for your actual work. But who knows, maybe it can give you inspiration if you want to implement some of the ideas for your own home-written tool.
The rest of the text on this page was written in older days when I still thought that AbaPerls could be of general interest, whence the tone.
Since these tools are general in nature, and address some problems that many SQL developers face – not the least the misfeature of deferred name resolution – I have put them in the public domain. The tools are used on every-day basis at one of my clients, so they are certainly stable. Then again, since they are developed them to meet specific needs, there are certainly are some rough edges and some funny shortcuts. And there is no denial that by now the tools have reached a level of complexity that getting started is a bit of a challenge.
The core purpose of AbaPerls from a CM perspective is to be able to build and update a database application from a version-control system. Currently, AbaPerls support Visual SourceSafe and Team Foundation Server. To achieve this, AbaPerls installs its own system tables in the database, so that when you run an upgrade script, AbaPerls knows whether the script is in sync with the database or not. An important part of this is that AbaPerls does not look at your database as a monolith, but you can divide the database into subsystems that you update independently.
For a developer, the most visible part of AbaPerls is the tool ABASQL which is used to load a file with SQL objects from disk or version-control to the database. ABASQL improves the experience for the developer in several ways:
Above I have mixed ABASQL and AbaPerls. ABASQL is just the command-line interface to the AbaPerls file-loading process which is also used by DBBUILD that builds an empty database and the update scripts you can generate with AbaPerls.
There are a couple of more features worth mentioning. The tool INSFILGEN permits you to generate INSERT-files for pre-loaded data from Excel books. And the tools SSGREP and SSREPLACE permits you to search and replace source code under version control (TFS or SourceSafe), ignoring comments in the source code. There is also a tool VCDBLOAD so that you can load all your source code into a fulltext-indexed database for more efficient searching.
AbaPerls presumes an environment of Windows, .NET and SQL Server. (SQL 2005 SP2 or later.) AbaPerls is implemented entirely in Perl. And T-SQL of course.
Just so you know it: AbaPerls is command-line only. There is no GUI.
To read more about AbaPerls, move on to the AbaPerls manual and read the introduction.
To download AbaPerls go to the download page. The current version of AbaPerls is L1.0.0402.
If you have any questions on AbaPerls, you can reach me on firstname.lastname@example.org.
AbaPerls is available under the Perl Artistic License.