You probably already know that you can access your ManuSoft data using standard ODBC drivers. This allows you to display your ManuSoft data in programs that support ODBC, like Crystal Reports and Excel. Another program that supports ODBC is Microsoft Access. Unfortunately, it appears that Microsoft Access' ODBC support is not quite as good as Microsoft Excel's, plus how you set up the links to your ManuSoft data in Access has changed quite a lot with each new release of Access.

Here are the steps for creating a "linked table" to your ManuSoft data in Access 2007:

1. Create a new blank Database.
2. Select the “External Data” ribbon, then in the “Import” section click on “More”, then “ODBC Database”, like so:
   
3. Select “Link to the data source by creating a linked table” and click “OK”.
4. In the “Select Data Source” dialog that opens, select the “Machine Data Source” tab, find and select “ManusoftDBF” in the list, then click “OK”.
5. Select the table(s) you want to link to. Use Ctrl-Click to select/deselect more than one entry, then click on “OK” to continue:
   
6. For each table to selected you’ll now be prompted to “Select Unique Record Identifier”. This is essentially asking you to select which field(s) make up the Primary Key for the table. This information can be found in Section 4 of the reference manual. For example, in the case of the Material database, the Primary Key is made up of the “partcode”, “reserved” and “item” fields, so I select all three of them (no need to hold down the Ctrl key this time) then click OK:
   
7. If the Database Navigator is turned on you should now see some new entries for the tables you have linked, each with a “globe and arrow” icon, like so:
   
8. Double-click on any of the entries to open the table and you should see some data, like so:
   
    

It *should* be as simple as that! What sorts of problems are there or might you face? 

• Amount fields will sometimes be rounded to 2 decimal places, even if you use more than 2 in ManuSoft.
• Other number fields may not support number as big or as small as in ManuSoft. This will display some sort of error message in their fields inside Access.
• $NAME or other funny error messages may be a result of a dodgy DBF file header. Do a Condense of the table in ManuSoft, then delete the linked table and add it again using the steps above.
• Note: If you hover your mouse over a linked table in the Navigator pane a tool tip appears showing the ODBC Link information. Part of this information is the path to the DBF files. Thus, if you copy the Access database onto another computer which does not have the DBF files in the same location, then the links will no longer work.

ManuSoft version 6.0 was our first version of ManuSoft for Windows and was written for Windows 95 specifically. We never did a version for Windows 3.11 or earlier. As such, ManuSoft 6.x has always been a 32-bit Windows program, written in pure Microsoft Visual C++.

Through Windows 95, Windows 98, Windows 2000, Windows ME, Windows XP and now Windows Vista, ManuSoft has remained a 32-bit program, and this is fine as it's what the vast majority of users out there are using. But just recently we're starting to see a few "64-bit Windows" users out there. These are people running "Windows XP 64-Bit Edition" or "Windows Vista 64-Bit Edition", sometimes also referred to as "x64" versions of Windows.

There is some software out there where special "x64" versions are produced, specifically for running on these versions of Windows. Microsoft has versions of their Microsoft Exchange Server and Microsoft SQL Server products that are designed for 64-bit computers, and Adobe has released 64-bit versions of some of their photo and video editing software. Programs that use a lot of RAM or do computationally intensive operations typically perform better as 64-bit software, but for the vast majority of programs there is little to no benefit in converting to 64-bit. You will not find a 64-bit edition of Microsoft Word, or even Microsoft Excel.

Similarly, we have no plans to produce a 64-bit edition of ManuSoft. There is simply no benefit for the user in us doing so. It would not make ManuSoft run any faster, or be any more efficient. 

So what happens when you run 32-bit software on your 64-bit edition of Windows? The answer is that the 32-bit program is run in a special way, launched through a process called WOW64 or "Windows on Windows64". WOW64 essentially provides an emulated 32-bit environment so that the older software thinks it is still running on a 32-bit machine. Any time the software tries to talk to the 64-bit operating system the WOW64 process steps in and provides a translation service so things continue to run smoothly.

 (Incidentally, a very similar thing was done back when Windows 95 was first released. Windows 3.x was a 16-bit operating system, whereas Windows 95 was 32-bit. In order for all the older 16-bit software to continue functioning, Microsoft provided a service called WOW32, which performed in exactly the same way.)

All this happens silently and seamlessly. You'll have absolutely no idea that the WOW64 process is being used while you are running ManuSoft.

There is one small discrepancy that you must be aware of though. Because ManuSoft is 32-bit, it will only talk to 32-bit ODBC drivers. This is fine as the 32-bit ODBC drivers continue to function on 64-bit Windows. But if you go into the "ODBC Administrator" on a 64-bit edition of Windows (found by going into "Control Panel", then "Administrative Tools", then double-clicking "Data Sources (ODBC)"), then what you have in fact started is the "64-Bit ODBC Administrator".  You'll find the ManuSoftDAT and ManuSoftDBF User DSNs are listed, but if you try to configure them you'll get error messages about "The setup routines... could not be found."

Instead, you need to run the "32-Bit ODBC Administrator", which you can do by clicking "Start", then "Run", then entering "%WinDir%\SysWOW64\odbcad32.exe" as the program you wish to open. This will launch an almost identical looking program, but this time you will be able to successfully click on the "Configure" button and modify the ManuSoftDAT and ManuSoftDBF entries (should you need to.)

It's always good to be able to get your ManuSoft data into other programs for further analysis or whatever. Anything that saves you tedious rekeying of data is a good thing, and is what computers are good at. A common requirement of our users is to be able to export some or all of their ManuSoft data into Excel in order to further manipulate it in some way.

The oldest way of doing this was to use the ManuSoft Report Generator to create a report with the data you wanted to export. You configured the columns, printed/exported the report to a text file, then opened that file in Excel. There, you had to go through an import wizard, confirming where the column breaks were and potentially what data type (text, number, date, etc.) each column was. Now you had your data in Excel and you could manipulate it how you chose, but when you came back a month later say, to do the same sort of thing, you had to go through the whole process again. But this method is still available today and is useful for one-off "quick and dirty" exports from ManuSoft.

Starting with ManuSoft v6.2 we created an ODBC link into ManuSoft databases. This allows you to grab information from ManuSoft from inside Excel itself, using the "Get External Data" feature with Microsoft Query. The advantage of doing things this way is that the Query is saved with the spreadsheet. This means you can reopen the spreadsheet days or months later, hit the "Refresh" option and have the latest ManuSoft data appear, without any need to rebuild things from scratch.

In v6.5 of ManuSoft we have introduced a new way which runs a middle ground between these two approaches. The first thing to consider here is the fact that now all ManuSoft reports are Crystal Reports it is possible to export them straight to an Excel file, which you can manipulate. But depending on the complexity of the report your results will vary - some reports come out looking all "neat and tidy" in Excel, other's can be a bit of a mess. The latter is true for the default report used by the Report Generator. But in v6.5 it is now possible to specify a particular Crystal Report to be used by the Report Generator, and by using this feature, and by using a particular Crystal Report, it is possible to very quickly create Excel spreadsheets straight from your ManuSoft data.

Firstly, go to the ManuSoft Support Site's Miscellaneous Files section and download the Export.rpt file and save it somewhere like your ManuSoft program folder. Next, in the ManuSoft Report Generator, create a report and on the "Other Criteria" tab set the "User Defined Report" field to "M:\Export.rpt" (where M:\ is where you saved the report). It doesn't matter whether the "Printout Style" is set to Print or Export. You can now print the report to screen using the "Printout" button. The report isn't very  much to look at (all the fields are very small, so almost all the text will appear truncated), but you can use the Crystal Report Viewer's "Export" button to save the output straight to an Excel spreadsheet. Open the saved spreadsheet in Excel and use its "Autofit" option to widen the column widths to display all your data, and you're done!