MDBC Reports are a powerful part of the ManuSoft System. They allow users to view Crystal Reports based on your ManuSoft data even if they don't have the full Crystal Reports product installed. We have many sample reports on our Support Web Site, and also run training sessions on creating Crystal Reports.

The MDBC Reports menu allows for up to 100 reports to be defined in the system. For each report you do several things: give it a name, enter the path to the report, and if any .DAT files are being used they all have to be ticked so that the program knows to copy the files into your User folder, so that the report is run using the latest data. After a while, this last part in particular can be hard to keep control of, and it's particularly tedious to change all these settings if, as part of your v6.4 or v6.5 upgrade, you change many of your reports from using the .DAT files to the .DBF files (and so they no longer need to be ticked.)

Enter another Excel Spread Sheet to the rescue! The MDBCReptSetup.xls spread sheet (you'll find it in the Miscellaneous Files section of the Support Web Site) allows you to quickly and easily see and change all the settings related to your MDBC Reports Set Up. Simply open the spread sheet (making sure you allow Macros to be enabled), click the "Load Settings" button and enter the path to your WORK.DAT file  (usually "N:\", though you may wish to initially start by working on your "C:\ManuPlay\" folder.) The spread sheet will be filled with all the entries in your MDBC Reports menu. The initial columns are fairly self explanatory, simply following the fields in the setup dialog of the MDBC Reports program. The columns with the titles rotated 90 degrees correspond to all the check boxes for the .DAT files. There are a handful which have titles in curly braces (e.g. {Unused}); these columns should be ignored and left blank. For the other columns, enter either a "1" where you do want the file to be copied down (equivalent to ticking the entry), or a "0" or blank where you do NOT want the file copied down (equivalent to leaving the option unticked.)

Once you've made the changes you need, simply click the "Save Changes" button to write the new settings back to your WORK.DAT file. Like most of these "outside the system hacks" that I've talked about, only rudimentary error checking is made of the values you enter, so take care with any changes you make, and if in doubt, make the changes inside the system itself using the standard menu. (You did make a back up of your WORK.DAT file first, didn't you?)

Long time ManuSoft users will probably already know that NULLs in your ManuSoft data files are a problem, but you probably don't know exactly what they are and why they are problem or how they get there. This entry is a quick discussion on the topic of NULLs.

So, firstly why "NULL" in all capitals? This is because we are referring to a particular 'control code' as defined by the ASCII character set. All modern PCs use the ASCII character set which defines how all the letters, number and symbols on your keyboard are stored as numbers in memory, as well as defining a number of non-displaying characters, like "CR" (Carriage Return), "LF" (Line Feed) and also one called "NULL". These non-displaying 'control codes' take up the first 32 positions in the ASCII table, numbered from 0 to 31, and NULL takes position 0.

ManuSoft has always attempted to avoid all control codes in its data files, for several reasons, but avoiding the NULL character is particularly important because in the C/C++ programming language that ManuSoft is written in the NULL character has a special meaning; it marks the end of a string of characters. So, say ManuSoft wants to read some information, like the standard wording for a Purchase Order, from your WORK.DAT file. In the C++ code we open the WORK.DAT file, position the read pointer at the particular location where that standard wording is saved, and issue a command to read in a block of 600 characters (the maximum length of the standard wording text.) If, for whatever reason, there was a NULL character at the 200 character mark then only the first 200 characters would actually be read by the C++ file sub-system. All the text you had typed in to positions 201 through 600 would be ignored and would not get printed.

Now that example is not particularly dramatic, but when you start considering other possibilities, like a NULL in the middle of a stock record, so that the stock code and description read and update just fine, but the quantity in stock seems to never change, and you can see what sorts of problems can appear. Sometimes quite inexplicable behaviour can be traced back to a NULL in an odd spot.

So how do NULLs appear in your files? ManuSoft obviously tries to avoid creating them itself wherever possible, but some further facts about the behaviour of C/C++ and Windows makes them crop up from time to time. Firstly, there's the problem of buffers. When ManuSoft wants to create a brand new stock record, for example, we initialize a 1024 character "buffer" in memory. We would then normally fill that buffer with exactly 1024 characters before writing the contents to the end of the file. But if for some reason the buffer was only filled with 500 characters then position 501 would contain a NULL (to mark the end of the string), and that NULL could then be written to the file along with the rest of the buffer.

A second main cause is a file being expanded when it is written to. If a file is 50,000 bytes long and a C/C++ program asks Windows to write some characters to the file at position 55,000, then characters 50,001 to 54,999 in the file will end up being NULLs.

And then there are just the regular glitches that can happen on any computer network given enough traffic and enough time. Because the NULL character is the "default" for unallocated memory, etc. if anything goes wrong with any transferring of information inside a computer or around a network then there's a good chance a NULL could end up in the data somewhere.

I said earlier that ManuSoft has always tried to avoid control characters in its data files, but over time we've had to compromise our position on this. The first was when we made the ManuSoft .DAT files compatible with ODBC access, back in Version 6.1. To allow the Microsoft ODBC Text Driver to read our .DAT files we had to insert the control characters "CR" and "LF" at the end of every record in the database, as this is the Microsoft DOS/Windows standard for marking the "end of a line". The next big change was when we converted to using the .DBF file format in Version 6.4 of ManuSoft. The .DBF file format defines a "header" that must appear at the start of every file, before the actual data. This header information includes many NULLs and other control codes. But despite these changes over the years the actual data itself inside our data files continues to exclude all control characters.

Because NULLs in particular are a problem in our data files we created a utility called "FixNULLs" which you can use to clean up your data files, changing all NULL characters to the harmless "space" character instead. This utility used to be a very ordinary looking "DOS mode" program which you had to run at the command prompt. After changing to the .DBF file format this utility has been updated to have a Windows interface and to be a lot more user friendly. You can queue up a number of files to all be checked (by browsing for them, or by drag-and-dropping the files from Windows Explorer) and when run the program gives more feedback and will automatically skip "safe" NULL characters in the the header section of any .DBF files.

The FixNULLs program can be downloaded from the Miscellaneous Files section of the support web site. It would be very hard for you to do any unwitting damage to your data files using this utility, but we would generally recommend you only use it after consulting with ManuSoft Support personnel.

ManuSoft System Administrators should already be aware that it is important that every user on the network is assigned a unique ManuSoft User Number for the system to operate correctly. If two users are given the same User Number then it is quite easy for the Record Locking System to fail, and it is this system that prevents simultaneous operations being performed on the same data inappropriately.

Thus it is always a good idea to keep close tabs on which users have been given which numbers, and to always be careful when adding new users to your network. We have often recommended that you occasionally perform a complete audit of ManuSoft User Numbers on your network, by visiting each user in turn and going into the "User Information" menu option under "System Maintenance" to check precisely what number they have been assigned. (Simply relying on the "Review/Reset Locks" display, which lists all the users and what program they are in, is not sufficient!)

For our larger clients doing such an audit is obviously a fairly tedious task, since there are so many users/computers to visit. To help in these situations I have developed a new Excel spread sheet, UserScan.XLS, and uploaded it to the "Miscellaneous Files" section of the ManuSoft Support Site. This spread sheet contains a macro which when run will seek out your USER.DAT files before displaying in the spread sheet the results of its search, which you can then sort in the normal way, making it easy to spot duplicate of missing User Numbers. Too easy!

Some notes on using this spread sheet:

1. The spread sheet can only work if your USER.DAT files are all being stored on the sever, not if they're on the local (C:) hard drives on each computer. Sorry.
2. When first opening the spread sheet make sure you read the security prompts and enable the macro stored in the spread sheet, otherwise things won't get very far.
3. When you click the "Start" button you will be prompted for a starting directory. You should be able to type in a "UNC Path" pointing to your user folders.
   For example, you have a folder (called "Users") shared out on your server (called "Server"). In that folder there is a folder for each login on the network (JimR, MichaelH, etc.) and in those folders you will find the ManuSoft USER.DAT file. Your server login script maps the drive letter H:, say, to each user's unique "home" folder, so your ManuSoft set up therefore is configured with either "H:\", or "H:\User\" as the "User Data File" directory in the System Installation routine.
   However, when you run the macro in the spread sheet you must enter "\\Server\Users" when prompted for the starting folder for the seach, not "H:\".
   Alternatively, if you are actually running the spread sheet on the server directly, then you may be able to enter the "real" name of the folder. For example, your "Users" share is in fact located in "D:\Data\Users", so when you run the spread sheet (on the server) you can enter "D:\Data\Users" as the starting folder.
4. All sub-folders of the folder you specify are searched, including sub-folders of sub-folders. This may take some time! The Status Bar in Excel should show you which folder it is currently searching, so you can monitor the macro's progress.
5. Depending on the security permissions set on your user folders you may need to be logged in as an Administrator for the macro to have sufficient privledges to go searching for those files.

I hope the "power users" out there find this useful. Let me know if there are any further enhancements you'd like to see made to this routine.