DB/TextWorks has been around since the late 1990’s and we sometimes come across clients with databases that were developed almost that long ago!  Two recent projects we are working on involve rationalizing older databases to modern standards.   It’s amazing how old, ugly, inefficient interfaces can be spruced up through the use of one of our kits for libraries, archives and museums.  We use these as a starting point, and after updating field names to be as descriptive as possible, we import our query screens, report and edit forms and adjust these to show the clients fields.  If you have report designs you like, you can do this too!  Under Maintain > Manage Textbase Elements you can import and export forms from one database to another.  We like to color code our databases and it’s possible to open the exported forms in Notepad or other text editor and carefully edit to replace background colors.

Inevitably requirements change over the years, so we help clients review how fields are being used, and suggest adding or deleting fields to better handle their needs.  We also make sure to add automatic number and date fields, appropriate validation and substitution lists and work with clients to clean up their data by batch modifying or updating values through the validation lists. After so many years working with DB/TextWorks we have a lot of tricks up our sleeves, and often export data, adjust it in other software and re-import to split or combine fields.

If you need assistance with your databases, please check out some of our past blog posts that provide various suggestions for improvements.  Note that some of these reference older versions of DB/TextWorks so the location of functions may not be identical.

• Succession planning and your databases

Spring Cleanup series:

• Part 1: Spring cleanup for your Inmagic textbases
• Part 2: Rationalizing textbase elements
• Part 3: Protecting and maintaining your textbases
• Part 4: Renaming fields

Give your databases a new lease on life and contact us for a quote to help you love them again!

We’ve heard recently from several long time clients that they are retiring soon or considering a move to another job. Most are concerned about their “legacy” when they leave, and so we have been talking about succession planning with regard to their databases.  Many have been using Inmagic software for many years and know it well.  However for their replacement coming in fresh, it’d be helpful to provide some documentation and background information, especially if there is no overlap and the new person will be faced with learning the software on their own.

Sometimes it’s hard to look at a system from an outsiders perspective especially if “it works fine and has always been that way”. For example, we came across a client recently who used basic everything, i.e. basic query screens, basic reports and basic edit screen.  He regularly needed to work on writing abstracts which often exceeded the default 3 lines provided in a basic edit screen, so he would use the scroll bar up and down to view the contents as he typed.  

Basic edit screen	Edit screen from the Andornot Starter Kit with field groupings, boxes sized for contents, added help tips.

It was something he’d never thought about, but he had to admit that creating a new edit screen with the box height set as unlimited made life much, much easier. Basic screens also always list fields in the textbase structure order, but fields may have been added over the years resulting in no logical groupings.  Think how confusing working with basic screens will be to a newcomer to your system!

We therefore suggest you make it easier on your successor by doing a check of the usability of your databases and writing up notes on your infrastructure. This will also be helpful for new IT staff, and if you have to contact Inmagic for support.

• Which version of the software is installed and what are the serial numbers?  What is the operating system of the server? Where is the software installed and who has access set up to use it?  Are there any older versions of the software that should be uninstalled?
• Where are all your databases located on the server?  In multiple folders?  Are any restricted to certain staff or have other special permissions? Do they have passwords? Are there any older copies that may have been saved as backups or are the remnants of recover operations?  Search for *.tba or *.cba to check, then delete the duplicate copies now to avoid confusion later. Are there any obsolete or test databases that could be deleted or archived?
• Are all your database field names clear and unambiguous?  In older versions of DB/TextWorks there was a limit to their length so we’ve seen some pretty cryptic abbreviations!  Are all the fields in use still?
• Do you have unused report forms or edit screens.  Are they named clearly and consistently?
• If you have Genie or WebPublisher PRO, where are these installed and what is the web address and full UNC server path? Do you have access to these folders?  If you have DB/Text for SQL, do you have access to the Admin tool? Is the Importer set up for automated import of data?  If so, what is the source and the format?
• For WebPublisher PRO are there test or unused query screens? Is the data live immediately or is there some script that transfer databases nightly to a webserver? (This can cause much head scratching trying to figure out why changes don’t appear if this workflow is not documented.)
• If you haven’t upgraded to version 15 or 15.5 yet, note that this requires an upgrade to your textbases and thus the textbase and forms creation date will be updated too.  This was previously a handy way of checking on the vintage to help determine the history and retention value.

Check out our series of blog posts from last year on Spring Cleanup for your Databases which provide some detailed suggestions covering many of these points:

• Part 1: Spring cleanup for your Inmagic textbases
• Part 2: rationalizing textbase elements
• Part 3: Protecting and maintaining your textbases
• Part 4: Renaming fields

See also our post on Retirement Planning for Servers. Please contact us if you need any assistance.  We are available to analyze your databases and infrastructure and can write up a report and/or implement changes to your databases to make them easier for your successor to work with.

In the first post of this series we wrote about cleaning up the files associated with DB/TextWorks and in the second we covered rationalizing your textbase elements.  In this post we’ll discuss some steps you can take to protect and maintain your textbases in good health.

Usually Inmagic DB/TextWorks textbases can function for many years without any intervention or problems. However if you do ever see a “Stop: textbase is in an inconsistent state….” message, please do NOT keep working in it! We have had clients tell us that they just ignore that message not realizing that the textbase might be corrupt. Frequently this message is just caused by a temporary loss of network connectivity while a record is being edited and can be fixed very quickly.

We recommend every so often running Check Textbase from Manage Textbases on a menu screen (i.e. without a textbase open). This will detect and repair problems in the textbase and your user file. The process generally takes just a few minutes for most textbases, but can take a while for very large ones. We suggest specifying Options to Repair Structural Problems and Rebuild 10 or more Damaged Indexes (depending on textbase size). If any problems are found these will be listed in the .chk file with a recommendation for action. Running Check Textbase in this manner will clear the inconsistent state message if it was just caused by a network glitch.

As part of your regular maintenance we also recommend confirming that you have a backup routine for your textbases. We have have heard some horror stories over the years.  Two clients had fires, and two had floods in their buildings.  One of these had no offsite backup and lost several years work.  Another client had all their textbases deleted by an over zealous IT guy who didn’t know what they were and figured they weren’t important, and another client hit batch delete instead of batch modify!  For many of our smaller clients without any IT support you can always simply make a backup by copying your textbases to a USB stick and taking it home with you.

The above information applies to the non-SQL version of DB/TextWorks. Clients with DB/Text for SQL versions should ensure their IT staff are aware of the recommendations in the Administrators Guide available from the Inmagic extranet.

For more information, check out the Help file built in to DB/TextWorks, or the printable PDFfor version 13.   If you run Check Textbase and need help implementing the recommendations, please contact Inmagic Support if you have a maintenance contract, or we can help you on a consulting basis.

In Part 1 of this series of blog posts on spring cleaning your databases,we wrote about the various files created by DB/TextWorks and what was safe to delete.

Now that you have successfully cleaned up the various folders with your textbases, it’s time to turn your attention to the textbase elements, i.e. the query screens, forms and saved sets within your textbases. 

Hopefully you have these!  We hate to find that clients are using the default basic query screen and basic forms when it is possible to create your own very easily. We have watched in horror as clients scroll down long edit screens to add information to a new field they just created which of course appears at the end of their data structure.  We recommend designing query screens and forms with fields placed side by side, grouped under logical headings to allow everything to be viewed at once without any need for scrolling. Additional text boxes can easily be added to all screens to provide helpful search or data entry hints.  So no excuses – try designing some forms – it’s not hard!

On the other end of the spectrum are clients who have created so many forms it’s not obvious which are the ones in common usage.  So they may have Report-Test or Label3 or QBE_Susan etc.  Regular users of the textbase may know which ones are appropriate, but think about our succession planning motive – how can you make it obvious to a new user which they should use?

You can see a listing of all the query screens, report forms and saved sets for a textbase under Maintain > Manage Textbase Elements (or Display > Textbase Information to view a printable list).  This list may show more forms than from clicking the Select Form icon, as some may be for printing or web use only.  Most will say (public) after the name – any that do not are visible to you only, and are stored in your personal user file (see Part 1of this spring cleanup series).

Caution:  if you are using WebPublisher PRO you will want to make sure you know which forms are being used in your web interface before any deleting or renaming.   If you are using menu screens or script buttons in your textbase, these too may be set to use specifically named forms. However it’s probably safe to delete ones with names such as test, report1 etc. but if in doubt, before actually deleting forms, we suggest simply renaming them.  They can then be renamed back if it is found they are still in use.   Under Manage Textbase Elements there is a Rename option.  We recommend keeping the same name prefaced with an x.  This means they will drop to the bottom of the list and it is clear that that they are pending deletion at some point.  You can also create a backup of all your forms first by selecting all of them (Shift click) and choosing Export to create an .xpf file.

It is good practice to note additional information in the Description line when you save a form, such as how it is sorted, if it is designed for a specific label size or for a particular function.  This can be invaluable when trying to ascertain years later why a form was created. We also recommend naming your forms consistently starting with an indication of how they are used, i.e. print only forms prefaced with Print as in the screenshot above.

For more information, check out the Help file built in to DB/TextWorks, or the printable PDFfor version 13. If you don’t feel comfortable doing this cleanup yourself or would like assistance designing forms or query screens, contact us and we can help you on a consulting basis.

Our next post in this series will cover maintaining your textbases in good health.

What might happen if you win the lottery?  Will your successor be able to understand how to use your Inmagic DB/TextWorks textbases?  In this series of posts we’ll help you rationalize your files, textbases and forms plus provide suggestions for regular maintenance of your textbases.

In this Part 1 of the series we discuss how to cleanup folders and directories which may have become cluttered with multiple copies and backups of textbases and related files.  Here therefore are some tips to help you figure out what is safe to delete.

What are all those files and what do they do?

Each DB/TextWorks database consists of a number of files; how many depends on whether you have the version for a non-SQL or SQL platform.  The SQL version, (file extensions shown in parentheses below), uses Microsoft SQL Server as the data store for the actual records. 

Do NOT delete any of the following:

.acf  (.cac)	Access Control File – controls simultaneous access to the textbase
.btx	Term and Word indexes
.dbo	Directory to the records in the .dbr file
.dbr	Contains the records
.dbs  (.cbs)	Textbase structure file with field definitions
.ixl	Indexed list file with any validation and substitution lists
.log  (.log)	Log file of any changes to records or the textbase structure
.occ	Lists of records indexed in the .btx file
.sdo	Directory to any records with deferred updates
.tba  (.cba)	Primary textbase definition file plus elements such as forms and query screens.
.tbm	Menu screen files

On a network install, you may also have .slt files which show who has a textbase open.  If you have a thesauri there will be .tml files, which prevent more than one person at a time modifying thesaurus records.   You may also have an .ini file for some applications.

What can I get rid of?

Generally the following are temporary working files created as you perform various functions:

.chk	Report created after running Check Textbase
.dmp	Exported records
.x01 etc.	Exception files from imports
.tbb (.cbb)	Exported textbase structure definition
.xpf or .xpq	Exported forms and query screens

These can usually be safely deleted unless there is a need to keep backups of the records or forms at some point in time.  If so, we suggest moving these files to a specific backup folder named appropriately to indicate the date and purpose.

How can I tell if it’s an old or defunct textbase?

We suggest doing a search across your network files for all *.tba or *.cba (SQL version) files.  You can use the Search or Find tool in Windows Explorer for this. This can have surprising results if you’ve had DB/TextWorks for many years!  It’s easy to create a new textbase or make a copy of an existing one to test out a new idea, but all too often these tests are never deleted.  Usually once you open these textbases you can search and see if there are only a few records. If there is no automatic date created field, we suggest looking at the log file to determine how long ago data was last added or modified to help determine current usage. For clients with multiple users and multiple textbases, we have a sample database inventory textbase to help you document this cleanup process. Contact us if you are interested in obtaining a copy - it’s free for existing clients.

What about all these .tbu, .tbs and .idi files?

These are all User Files and are specific to each person who is using each textbase in DB/TextWorks.  The .tbu contains “private” textbase elements such as forms and saved sets.   The .tbs file stores scripting information and the .idi file stores your last used settings, such as the window size and position, and your most recent batch modification or import settings.
Ideally these should be stored in a personal User Files folder on the network for each user so that there are no conflicts and to ensure that they are backed up.  You can also store them on your PC workstation if it’s backed up. However if you want to keep these settings you’ll need to remember to copy those files over if you get a new PC.

You can easily move these personal user files to a more appropriate location under Tools > Options. We highly recommend checking where they are now located for each active user and rationalizing these settings.   You can then safely delete any remaining .tbu, .tbs and .idi files if they are currently cluttering up your textbases folders.

For more information on any of these files, check out the Help built into DB/TextWorks or the printable PDFfor version 13. If you don’t feel comfortable doing this cleanup yourself, contact us and we can help you on a consulting basis.

Spring Cleanup Part 2:  Rationalizing textbase elements