How To Create a DB/TextWorks Menu Screen

by Jonathan Jacobsen Thursday, November 15, 2018 10:36 AM

For some reason, DB/TextWorks menu screens are a little used feature. We often meet clients with many databases, but without a convenient way of seeing and accessing them all at a glance. Adding a menu screen to DB/TextWorks is quick and easy to do, but makes using your databases so much easier.

The screenshot above shows the menu screen from our Andornot Library Kit, with links to each of the many databases it includes. The one below shows one from one of our clients' systems.

What is a Menu Screen?

Like a Query Screen or Report Form in a DB/TextWorks database, a Menu Screen is a screen layout you create using the WYSIWYG designer in DB/TextWorks. You would usually add to it links to each of your databases, for searching or data entry. You might also add your organization's name or logo, contact or support info for anyone who might be using the system, a brief description of each database, etc.

Having links to all your databases on a single screen saves time and helps new users find their way around your collection of databases without having to hunt for them in folders on disk. It also allows you to specify, in each link to a database, which query screen and reports to load for that database. 

One way to create menu screens is to have different menu screens for different kinds of users. For example, in an archives or museum that relies on volunteers to help with data entry, you could have a menu screen for volunteers that only lists the Accessions database, and pre-loads a simpler query screen and data entry form designed specifically for volunteers. A more extensive menu could provide the archivist or curator with links to all databases, pre-loading the more sophisticated query and edit screens for their use.

Unlike a Query Screen or Report Form, the menu screen isn't stored in any one database, but rather as a separate file on disk (with a .tbm or .cbm extension). You would usually store it in the same folder as all your database files.

How do I create a Menu Screen?

  1. Open DB/TextWorks but don't open a database.
  2. Select Menu Screens > Design from the main menu.
  3. Choose "Create a New Menu Screen File."
  4. Browse to the folder where your databases are stored to save the menu screen in the same location, and give it a name.
  5. In the WYSIWYG Menu Screen Designer, you may now add links to textbases, your organization's name or logo, and other information. Use the examples above for ideas, or come up with your own design.
  6. To add links to textbases, choose Edit > Add > Textbase box.
  7. In the Textbase Properties Dialogue, select the textbase to link to, then on the Initial Elements tab, pre-select the query screen and forms to use by default. Note that these override the default screens and forms set in the textbase, and that in either case, users may still change to other screens and forms once they are in the database.
  8. On the Initial Action tab, be sure to select which window to open. For example, if your link is one such as "Search the Database", select a Query Window. If your link is "Add a New Record", select Edit New Record as the window to open.
  9. Save your new menu screen when your design is complete.
  10. If you ever create more than one menu screen, you can even add links from one to another on each of them.

How do I use a Menu Screen?

  1. On each PC that has DB/TextWorks, open DB/TextWorks but don't open a database.
  2. Select Menu Screens > Select from the main menu.
  3. Choose "Use the Menu Screen in a File", then browse to and select the Menu Screen file (ending with .tbm or .cbm) that you created earlier, usually stored in the same folder as your databases.
  4. Close and re-start DB/TextWorks and your menu screen will now automatically load, ready for use.

See this blog post from earlier this week about two other helpful but little used features of DB/TextWorks: Sets and Record Skeletons.

3 under-used DB/TextWorks functions that you might find useful

by Kathy Bryce Tuesday, November 13, 2018 9:28 AM

A recent project has reminded me that many clients are not aware of the power of these three functions that have been available in DB/TextWorks for years, and which can potentially streamline and speed up your workflow.

The first is Menu Screens.  Many clients have a menu screen that loads up when they open DB/TextWorks but usually the ones we see are either the default from the old Inmagic Library Module, or rudimentary boxes linking to their databases. However they can be so much more useful! Here is an example from a recent project.

CLGA menu

A menu screen is super easy to set up and we’ll be posting a detailed guide here in our blog soon.

However first we need to discuss the other two functions, as they can be used separately or in conjunction with your menu screen.

The second function is Sets. Whenever you do a search you can choose to Save the Set from the top toolbar. Sets are a great way of providing quick access to a search with several parameters to save you from entering them each time using the query screen. So for example, find all records with a Review date in the next 30 days; or find digital image records that have been entered but not checked yet; or find all books that are not on permanent loan and that have been out for more than 60 days. You can use the @date variable in the search strategy without needing to actually input an actual date each time. Never used the @date function? It can be very handy especially when combined as in @date-7:@date which retrieves all dates within the past week.   A Sets box can be added to your query screen to give you quick access to running these searches or they can be embedded in your menu screen.

The third function is Record Skeletons. You may have a student or volunteer adding records for reports in particular series; or images in a photographic collection; or documents in a fonds. You can create a record skeleton to prepopulate the edit screen with publication or descriptive data that is common to all these new records. You can find Skeletons under the Records menu. Note that once you select a skeleton to use, it will be the default until you re-set to none, or choose a different one.

In the menu screen example above, every database has a link to the search screen plus a link straight in to a new record edit screen. If your database has several edit screens these can be specified on the menu screen too, as well as specifying a skeleton appropriate for these new records. It may not seem like much, but this can save a couple of extra clicks and let you get straight to work. This screen also has Sets specified to prepopulate the query screen with the value for a particular collection. So easy to set up and a great way to ensure people can search quickly and effectively.

Check out more tips and tricks for getting the most out of DB/TextWorks in our blog archive:

We are always available to help you with updates to your databases. No project is too small!

10 Ideas to Improve your Web Presence and Help Your Users Find You

by Jonathan Jacobsen Tuesday, September 25, 2018 8:40 AM

As the air gets crisper and precipitation drives us indoors, Fall is a great time to reflect and to find energy for new projects and adventures.

Have you thought about the web presence your museum, archive or library collection has? Are you providing users with modern tools to help them research your records and share them with others. Here are 10 ideas to read on a blustery Fall day, and that could add some sparkle to your website and online collections.

  1. Upgrade to a more modern search engine, such as our Andornot Discovery Interface, with features users expect when searching. For example, see how we helped Forestry Innovation Investment with their ThinkWood Research Library.
  2. Add ever more historic content to attract users interested in local history and genealogy, like the Arnprior & McNab/Braeside Archives did with back issues of the Arnprior Chronicle newspaper.
  3. Add a map interface so users can browse geographically, like the one we built for the Ontario Jewish Archives.
  4. Have lots of documents? Why not index the full text of them, then when a user searches for keywords, take them directly to the most relevant page in the PDF. No more downloading and repeating the search within the PDF to find the right page. Learn more.
  5. Get out in front of Community Engagement by adding the Disqus commenting system to your search results, so users can more easily discuss items in your collection, help identify people and places, and provide feedback to you.
  6. Make sure your website or search engine is mobile friendly. Google and other search engines now place mobile-friendly results higher in their rankings. And make sure you have a sitemap and permalinks so your collection can be easily indexed by Google and Bing.
  7. Planning to digitize large works, such as maps, paintings, or architectural drawings? Will users be able to see the fine detail in the resulting images on your website or in your search engine? Our Image Zoomer can help, by allowing users to easily zoom in on specific areas of a large image, without having to download that very large file.
  8. Is your website looking dated? Maybe it has the digital equivalent of large shoulder pads or flared pants? Time for a refresh? Let us help with a Content Management System and new graphic design, like we did recently for PRCVI (the BC Provincial Resource Centre for the Visually Impaired).
  9. Can't attract the attention of your own IT staff to help with your website or software? Why not have Andornot host it?
  10. On a tight budget? Consider our low-cost Digital History Hub platform for putting collections online and making virtual exhibits.

Contact us to discuss any of these ideas, and ones of your own.

Snazzy up your DB/TextWorks databases!

by Kathy Bryce Wednesday, July 04, 2018 10:58 AM

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. Archives_Accessions

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.

Spring Cleanup series:

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

Converting DB/TextWorks Data to MARC: Not as Easy as it Sounds!

by Jonathan Jacobsen Wednesday, April 25, 2018 4:55 PM

We recently had a client ask us if we could help them convert their DB/TextWorks library catalogue database to MARC format, for submission to another search system.

Our initial reaction was "Sure, easy-peasy." After all, we're librarians, we know MARC well, we're experts in DB/TextWorks, and we've done this before. How hard could it be?

Ha! Famous last words, and all that.

To be fair, there are a few wrinkles:

  1. The conversion is not a one-time affair, but rather something the client would like automated and running on a regular basis.
  2. Not all records in the database are to be converted.
  3. MARC is not the simplest of formats. Whether MARC or MARCXML, there are a fairly rigid set of rules that must be followed to create 100% valid, standards-compliant MARC records.

Nonetheless, since MARC has been around rather a long time, there are a plethora of tools available for creating MARC records from other data sources. There's Inmagic's own MARC Transformer, which works directly with DB/TextWorks databases, as well as various free or open source tools from the U.S. Library of Congress and other agencies, MARCEdit, Balboa Software's Data Magician, and others.

We also have our Andornot Data Extraction Utility for automatically exporting data from a DB/TextWorks database and manipulating it into a variety of formats.

Ever optimistic, we figured some combination of these tools could be strung together in sequence without too much effort to create a solution for this client. We wanted to avoid developing a DB/TextWorks-to-MARC conversion program from scratch as it would be quite time consuming, mostly due to the MARC format requirements themselves.

Several tools, upon closer investigation, proved to be too ancient to run reliably on a modern Windows server, or couldn't work with the current version of DB/TextWorks. Others proved almost impossible to use in an automated fashion. They could be useful in a one-time manual conversion to MARC format, but not in the hands-off, automated workflow we needed.

The exploration of this issue was an interesting exercise in seeing how old data formats and old programs age and become harder to work with.

The recipe that baked the cake in the end was:

  1. Use the Andornot Data Extraction Utility and the Inmagic ODBC driver to extract data from the DB/TextWorks database to a pseudo-MARC plain text format. 
  2. Use a custom-developed PowerShell script to manipulate the records in this file to handle some of the quirks of the ODBC output and to more closely adhere to the MARC format.
  3. Use the command line interface to MARCEdit to convert the pseudo-MARC to MARC Communications Format files.
  4. Upload the MARC files over FTP to the destination server.
  5. Manage all the moving parts through a PowerShell script and log the steps and results to a file for easy troubleshooting in case of problems.
  6. Run the script nightly as a scheduled task on a Windows server.

When written like that, in hindsight, it sounds so simple. And in the end, it was, and works well. But the journey to arrive at this solution was one of the more challenging small projects we've undertaken, considering how simple the task sounds at first.

We hope this will help you if you have a similar project, but don't hesitate to ask us for help, now that we've worked through this.

Month List