Skip to the content Back to Top

Inmagic has released version 15 of DB/TextWorks, WebPublisher PRO and DB/Text for SQL

Highlights of this release include:


  • New Field Type: Rich Text. The Rich Text field type permits you to change fonts (font name, size, color, bolding, italics, etc.) within a single field, align text, create bulleted lists, and so on. 
  • New Field Type: Call Number. When records are sorted by a field using the Call Number field type, Call Numbers are sorted the correct order.
  • Email Enhancements: Email dialogue more closely resembles sending mail from an email client, and includes fields for additional message text and a signature.
  • Limits on the number of fields, characters in field names, linked textbases, forms, query screens, and many other features have all been increased.
  • Substitution Lists: Additional Field Types now support Substitution Lists: Call Number, Code, Image, Link, and Number.
  • Import Document. Improved IFilter text extraction for PDF files, especially those with text in the margin. Also, line breaks are added after each period-space (". ") to improve readability.
  • HTML, XML and Text Encoding enhancements for increased compatibility.
  • As well as features for publishing to the web, assorted small fixes, and a few older, less-used features removed.

More information is available in the DB/TextWorks Version 15 Read Me.

WebPublisher PRO

  • Issues addressed with the InmagicBrowse app, and new features added for publishing to the web from DB/TextWorks.

More information is available in the WebPublisher PRO Version 15 Read Me, as well as the DB/TextWorks Version 15 Read Me and the DB/Text for SQL Version 15 Read Me.

DB/Text for SQL

  • In addition to the features added to DB/TextWorks and WebPublisher (see above), DB/Text for SQL is now supported on SQL Server 2014.

More information is available in the DB/Text for SQL Version 15 Read Me.


All clients with a current Inmagic maintenance subscription will be receiving emails from Inmagic with download instructions for this release.

This release also includes a new version of the PowerPack (Importer, Checker and Updater apps), popular for automating data import and full-text extraction and indexing, as well as the search-only DB/SearchWorks version of the software.

A new version of the ODBC driver is expected within the next couple of weeks.


Important Notice

Upgrading the Inmagic software to version 15 requires a change to textbase structures. Once made, only version 15 of DB/TextWorks and WebPublisher PRO will be able to access the databases. Therefore, plan to upgrade all servers, workstations and databases at once.

Clients using the ODBC driver should not upgrade to version 15 of DB/TextWorks, nor upgrade their textbases, until version 15 of the ODBC driver is released.


Please consult the system requirements and supported OSs and web browsers for DB/TextWorks, DB/Text for SQL and WebPublisher PRO,  available on the Inmagic Extranet.


If you have a current Inmagic maintenance subscription but have not received a notification email in the next week or so, please email with your serial number and email address so it can be resent. Please also remember to let us know if your contact information has changed so we can update our records and pass this on to Inmagic.

As always, contact us with questions, for assistance with this upgrade, or to renew an expired Inmagic maintenance subscription.

It's enlightening to visit with clients and find out how they are using Inmagic software, especially when they are not typical applications.  We are always suggesting maximizing your return on investment by using the software for anything and everything, so here is a great example of a client doing just that.

Last week I was in Toronto and met with Dave Hook at MDA, a long time client and user of Inmagic software.   Dave has some very cool applications with over 30 different DB/TextWorks databases populating much of their intranet content.  He showed me a few of these such as their home page which displays the latest news, plus their system for listing the latest training courses and how users can register for these online.  Following registration, the user’s supervisor is notified by email, the number of remaining available spaces updates until the class is full and then an attendee list can be printed out by the instructor.  Behind the scenes multiple DB/TextWorks databases are in play.  The web interface including all data entry for many of the databases is handled exclusively by ODBC calls into the databases using standard SQL queries written into each HTML page.  This results in pages that don't look like they were generated from a database but fit seamlessly into their intranet interface.

Dave also uses DB/TextWorks for quick prototyping of database ideas for various projects.  As it is so easy to add fields and functionality, he is able to build these prototypes and have users critique and suggest modifications in a very short time frame.  If applicable, the prototype can then be finalized as an Inmagic application, or used by their IT group as a basis for building a system in SQL or other software.  This prototyping process is very much in sync with our philosophy of launching fast, and refining later. 

So, just like Dave at MDA, don’t be restricted to just traditional uses for the software! Let us know if you have ideas for new databases that you would like us to help you with?

There are three ways to set up a DSN for ODBC connections: System DSN, User DSN, and File DSN. The first two store the connection settings in the registry, while the third stores all the connection info in a text file. The latter can be easily copied, filed with its parent project, put in source control, and modified by a build process. Plus just having that file there is a reminder that an ODBC connection is an application requirement. (Oh, I *have* forgotten.)

Create the file DSN

You can create a file DSN by opening the ODBC Data Source Administrator dialog (listed as "Data Sources (ODBC)" from the Windows Start Menu), but I have encountered problems doing it that way.* It's easy to do from scratch, anyway.

  1. Create a text file with a .dsn extension: MyFileDsn.dsn
  2. Fill in the contents as follows:
   1: [ODBC]
   2: DRIVER=Inmagic DB/Text Driver (*.tba)
   3: READONLY=1
   4: SERVER=NotTheServer
   5: DBQ=c:\project\textbases\
   7: UID=


  • Each key-value pair is on its own line separated by a carriage return. Ignore the fact that the view you're looking at on the blog may be wrapping.
  • The Inmagic ODBC driver must be installed on any machine using this connection.
  • ReadOnly can be set to 1 for readonly access. READONLY=0 means write access as well.
  • PWD can be blank if the textbase(s) don't use passwords.
  • UID is always blank.

* E.g. password not being written to the file DSN, and the potential for confusion between 64bit and 32bit ODBC Data Sources, since a 64bit machine has both and has separate Admin dialogs.

Use the file DSN

Pass a connection string to your application which points to the file you created:

   1: // C# file DSN example
   2: string connectionString = "filedsn=c:\MyFileDsn.dsn";


I just spent 20 minutes letting head bonk sharply and repeatedly on desk over Inmagic ODBC's "unable to open table" error, because I FORGOT that the ASP.NET worker account on Windows XP is aspnet, not network service, like it is with Windows Server 2003. I kept upping the permissions on network service to no avail. It was like I'd strapped bananas to my feet instead of shoes for the Summer Fun 10K of Broken Glass Run, and then, when things went badly, tied on bigger and bigger bananas.

I remembered today, with Ted's help, a technique which I really dig for retrieving the just-created textbase record when using ODBC Insert. 'Cause you don't get back any textbase-produced stuff like an autonumber RecordID or DateTimeEntered or anything, when using Inmagic ODBC to insert a record. There's just this kinda whistly sound the little integer-that-could makes as it tumbles its tumbleweedy way back from the database. "1" for "ayuh, I reckon we got ourselves a new record", and "not 1" for "they saw us comin' and Li'l Joe's been shot!" Or. Yeah. And that is the lamest wordplay ever in a title.

Okay so, I have used things like SELECT MAX(ID) FROM [tb] WHERE Title = ? to fetch what I just inserted, not yet knowing the ID, since it's produced in the BLACK BOX down there where the database is. And that's worked because it's unlikely that a field like Title, even when not unique, is going to repeat often, and since each new ID is an integer based on last-produced-integer +1, it's very very likely I'm going to get the record back that I just inserted.

Ted and Nathan have used unique fields or field combinations that have a statistically high unlikelihood of repeating. But still, it's bothered me that the method is not airtight. And today I remembered something Nathan had come up with: produce a GUID, stick it into the textbase along with the rest of the record, fetch record by GUID. So simple and effective. One needs to add a new field for it, but so what? And creating a string GUID in VB.NET is dead-easy: System.Guid.NewGuid.ToString().

Ahhh. Relax... the Andornot Way.


Let Us Help You!

We're Librarians - We Love to Help People