Monday, May 16, 2016 8:23 PM
Andornot recently helped a municipal archives save hours of manual work when civic records are transferred to them, by automating part of the data transfer process.
This municipal archives uses Inmagic DB/TextWorks to manage their collections. The many departments in the municipality complete a form when they are transferring records to the archives. The form is a fillable PDF form, but when the archives receives it with the records, they still need to re-key, or copy and paste, data into their DB/TextWorks system.
This fillable PDF form was altered so that a Submit button placed prominently on the form generates an XML file in Adobe's .xfdf format. Andornot developed an XSLT that can be used by DB/TextWorks' data import feature to transform data from this XML file into DB/TextWorks records. The XSLT selects appropriate data from the XML, and adds some default values like the material type, some notes, etc.
Dozens of records can now be imported in seconds or minutes, ready for the archives to review and edit further.
Further automation is also possible using the Inmagic Importer, which can monitor a folder and import files when they appear. This would allow the archives to drop multiple XML files from the transfer forms into a folder at once and then a few minutes later, access those records in the DB/TextWorks database.
Approaches like this are great for all sorts of institutions. Another common example is libraries sourcing catalogue records from other catalogues, such as by using BookWhere software, and importing those records into their catalogue, through DB/TextWorks or Genie.
Contact Andornot for assistance improving your workflow and automating repetitive tasks like this example.
Tuesday, May 03, 2016 8:45 PM
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:
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.