Syspro 7 Prerequisites

The prerequisites for Syspro 7 are listed in various places throughout the document, SYSPRO 7 Installation Guide.pdf; here are those prerequisites, collated in one easy place.

In short, Syspro 7 supports, and would be best deployed on the latest Windows servers and operating systems:

• Windows Server 2012
• SQL Server 2012
• Windows 7 and Windows 8 clients, x64.

Server Prerequisites

The SYSPRO 7 Application Server prerequisites include:

• Microsoft Windows Server 2003 (or later) or 
• Microsoft Windows XP SP3 (or later) 
• Microsoft .NET Framework 4.0

(Some features, e.g. Workflow Services, are limited on XP and 2003 Server as those versions of Windows do not support the .Net Framework 4.5 - see below.)

The SYSPRO Communication Service prerequisites include:

• Microsoft ® .NET Framework 4.0
• SYSPRO 7 (server installation)

The SYSPRO Workflow Services application server installation prerequisites include:

• Microsoft ® .NET Framework 4.5 
• A SQL Server installation of SQL 2005/SQL Express 2005, or higher, for each SYSPRO company 
• SYSPRO 7 (server installation)

The SYSPRO Reporting Services prerequisites include:

• Microsoft ® .NET Framework 4.0 
• SYSPRO 7 (server installation) 
• Crystal Server Runtime 
• Java Runtime

The SYSPRO WCF Services prerequisites include:

• Microsoft .NET Framework 4.0
• SYSPRO 7 (server installation)

The SYSPRO Web Services prerequisites include:

• Microsoft ® .NET Framework 4.0 
• Internet Explorer 6 (or higher) 
• Windows XP SP3 (or later) 
• Internet Information Services (IIS) 6 
• IIS6 Compatibility 

Note:
If the .NET Framework is installed before IIS you will need to run aspnet_regiis.exe.

Client Prerequisites

The SYSPRO 7 Client prerequisites include:

• Microsoft ® Windows XP SP3 (or later) 
• Microsoft ® .NET Framework 4.0 

Note:
Windows XP SP3 will require a Hot Fix in the form of sxs.dll which is available to download at http://support.microsoft.com/kb/943232

The SYSPRO Communication Service Client prerequisites include:

• SYSPRO 7 (server installation) on the server 
• SYSPRO Communication Service on the server 
• SYSPRO 7 (client installation) on the client machine

The SYSPRO Reporting Services Client prerequisites include:

• Microsoft ® .NET Framework 4.0 
• Java Runtime 
• Crystal Runtime

The Crystal Designer prerequisites include:

• Microsoft ® .NET Framework 4.0 
• Java Runtime 
• Crystal Runtime

The Crystal Dashboard Design prerequisites include:

• One of Microsoft Excel 2010 (32-bit), Excel 2007, Excel 2003 or Excel XP

The SYSPRO Factory Scheduling prerequisites include:

• Microsoft ® .NET Framework 4.0 

The SYSPRO Graphical Planning Board prerequisites include:

• SYSPRO Factory Scheduling Foundation

The SYSPRO Finite Scheduler prerequisites include:

• SYSPRO Factory Scheduling Foundation.

The SYSPRO Graphical Planning Board prerequisites include:

• SYSPRO Factory Scheduling Foundation

Developing .Net User Controls for Syspro - Intro

Syspro gives you the ability to house a .Net User Control inside the Syspro application, in a custom pane. (A custom pane can be housed in nearly any Window in the Syspro application, or in the Syspro main menu.) The custom-written control can then interact with your Syspro user interface, the Syspro database, and the Syspro Business Objects - so it's a very nice way to write custom solutions.

However, there are a few traps for the uninitiated:

1. You need to start with a WinForm user control because Syspro can’t run WPF user controls directly; not hard to resolve; you just add a WPF user control inside your WinForm user control.
   
2. You need to add Assembly Resolver code so that your DLL’s are loaded from ManagedAssemblies rather than BASE. See this post on the Syspro Forum for details.
   
3. You need to override the loading of configuration files as the .Net default of BASE\IMPACT.exe.config is obviously inappropriate.
   This code is good: http://stackoverflow.com/questions/6150644/change-default-app-config-at-runtime
   
4. There are some traps with calling Business Objects from .Net via Syspro's VBScript interface.
   In short, you need to:
   
   A. Avoid going over the 70-character limit, so passing XML files via temporary files is one solution.
   
   B. Avoid using spaces, new lines, or other characters, that are of significance to VBScript, in the strings you pass from .Net to Syspro's VBScript. The way to solve this is to encode all those characters as control characters before passing them to VBScript, then decode them inside the VBScript.
   
   C. You may need to pass more than two parameters to Syspro from .Net, but you only have two variables you can use. One way to solve this is to combine several parameters into one string, separating them with control characters.

Recommended Naming Convention for custom tables and fields

If you add custom tables or fields directly to the Syspro database, it is highly recommended that you use a naming scheme like these examples:

• CUSTOM_YourTableName
• USR_YourTableName
• CUSTOM_YourFieldName

The guidelines for the naming convention are:

1. The first word is in ALL-CAPS and should be the same word used for all customisations; CUSTOM or USR are the recommended words to use. CUSTOM is recommended over CUS because CUS is abbreviated and ambiguous with "Customer".
   
2. The actual meaningful table or fieldname should be in CamelCase without underscores.
3. The two words, CUSTOM and YourTableName, should be separated by an underscore.

The reason why the first word, CUSTOM, should be in ALL-CAPS is so that:

1. It makes all custom-added tables (and/or fields) stand out visibly from the standard Syspro ones.
2. It groups all the custom-added tables and fields together.

Guidelines for adding custom tables and fields to Syspro

It is very easy to add custom information to Syspro.

There are a few ways you can go about it.

1. Use a User-Definable field

There are some spare fields in Syspro; they usually go by the name of "user-definable field", but there are not many of them. Here are some of them:

• SorMaster.User1
• SorDetail.MUserDef

The advantage of using these fields is that they can usually be passed or retrieved as standard parameters in the relevant Syspro Business Objects.

2. Use standard fields

There are several fields to which you can add a LOT of information in Syspro:

• Notes - Many tables have free-form notes in which you can write a large amount of text.
• Files - You can attach files to may Syspro tables - multimedia files, pictures, diagrams, etc.

3. Create a Custom Field

You can add custom fields, via the Syspro GUI, to just about any Syspro table and screen. The advantage of doing things this ways is that these custom fields are editable by the Syspro user, without any extra code needing to be written.

In Syspro 6.1 and earlier, these custom fields are stored in the AdmFormData table.

In Syspro 7, these custom fields are added to the actual table (e.g. InvMaster).

These fields can be written and retrieved using these business objects:

• COMSFM - create/update custom fields
• COMQFM - query custom fields

Using the AdmFormData does come with a bit of friction – having to write the extra calls to save or retrieve the custom fields using the Business Object or messy joins in SQL, plus having to obtain the correct key fields.

However, this would normally be the recommended way of extending the data stored in Syspro.

4. Update the database schema

You CAN update Syspro's database schema, provided you adhere to the following rules: 

1. You can ADD tables and indexes to Syspro. This is the safest way to go.
2. You can ADD fields to existing tables, but adding separate tables is recommended over this option as it keeps everything entirely separate.
3. You must not delete any standard schema objects: tables, fields, indexes, relations, etc.

If you update the database schema, it is highly recommended that you follow the Recommended Naming Convention for custom tables and fields.

How to install Syspro 7 - Server

These are the detailed steps needed to install Syspro 7 Server on a Windows computer, preferably Windows Server, although Syspro 7 will suffice.

The installation is actually very easy - you would normally simply accept all the default values, and you normally wouldn't need the rest of this document, except when you hit the occasional problem.

1. Installation

From the Syspro 7 installation CD, run Autorun.exe, then click Server Installation, as highlighted in the screen shot below:

Click Syspro 7:

Select all the components you want installed:

If you are upgrading from Syspro 6.1, you may get asked to close some programs.

Before you do, BACKUP your Syspro 6 WCF Communications Service configuration file, as Syspro will remove the Syspro 6 Communications Service. This is because the Syspro 7 Communications Service is backwards compatible with the Syspro 6 one, but your config file gets deleted.
My config file was in C:\SYSPRO\SYSPRO Communication Service\SYSPROCOMMSService.exe.config.

Then click Yes:

Click Yes to install the Syspro 7 Runtime:

If you are doing an upgrade from an earlier version of Syspro, you may get asked the following; answer Yes:

Click Next:

Accept the licence agreement and click Next:

Decide whether you want to do an upgrade or a new installation, and click Next:

Select the components you need to install. You would not normally select any of these components as they have been superceded by Syspro WCF, Syspro Communications Service, etc.

Note for Syspro 7 RC010: you may wish to install the SQL ODBC Data Source so that you can connect to your database via ODBC, as you can't use the direct SQL Server conneciton as there is a bug in Syspro 7 whereby, when the direct SQL Server's connection string's UID is left blank.

Alternatively, you might select to install the SQL ODBC Data Source:

If installing the ODBC connection, you will get asked for connection information:

Click Install:

After a while you will get this screen; click Finish:

Next you get prompted to install the Syspro Communication Service (recommended):

Select the directory where you want to install the Syspro 7 Communications Service. If you are installing multiple versions of Syspro in the same machine, you may wish to use a directory that won't overwrite an existing installation. Then click Next:

Click Next:

Click Close:

When done, click Exit:

2. Setup

After Syspro has been installed, you need to set it up. To do this, run Syspro 7 from your Start menu on your server. You should see a welcome screen like this; click Next:

Select the Nationality and Date Format:

Set the password for the Administrato. It is advisable to set a password!

Select the type of database you want to use. Normally, you'd want to just select All companies are SQL Server based:

Alternatively, you might selected a mix of SQL Server and ISAM databases:

Select what sort of authentication you want to use.

However, as of Syspro 7 RC009, there are bugs in the use of SQL authentication whereby the connection string leaves the UID blank, and using the ODBC Data Source doesn't seem to work either, so you should select Windows Authentication, or use RC010 which has fixed this problem.

Note that to get Windows Authenticaiton to work, you will have to:

1. Set your SQL Server to use Mixed-Mode: in SQL Server Management Studio, right-click on your server and go to Properties; go to the Security tab; set Server authentication to SQL Server and Windows Authentication mode.
2. Give your Windows login sysadmin rights: in SQL Server Management Studio, expand your Server, then under Security, right-click on Logins and select New Login. Enter your Login name. Go to Server Roles and tick sysadmin.

Enter a SQL Server Login name and password. You should create a login name such as "syspro"; it's bad practice to use the "sa" login. Tick "All SYSPRO operators will use this SQL Server login".

Enter your connection string for SQL Server.

Note that there is temporarily, in the release candidate, a problem with using connection strings - there is an error in COMLGN were  Callbo does not work (and SRS), so you should use a System Data Source Name (DSN).

If you are connecting via a DSN, then you will need to manually create an ODBC data source first, unless you selected to install the SQL ODBC Data Source as part of the installation earlier.

Enter the name of the Syspro system-wide database; you'd normally leave this unchanged as Sysprodb:

The ensuing steps are fairly straight forward and so are not listed in detail here.
__________________________________________________________________________

If you hit an error such as:

Message: Incorrect open mode for fle type
Access: Attempting to open a file
File name: C:\SYSPRO7\WORK\IMPACT.INI
Status: 37
Program: IMPNEW - Admin First Time SYSPRO Installation

then you may need to give additional permission on the Syspro WORK directory, as shown in the screen shot below:

__________________________________________________________________________

How to fix the dreaded Grey Screen of Death in Syspro

If you add a custom-written .Net User Control to a custom pane in Syspro, you can easily get the dreaded Grey Screen of Death - a blank grey screen (see screen shot below).

One of the most common reasons for this happening is that Syspro can't find one of the DLL's needed by your .Net solution. So where does Syspro look for the DLL's?

1. The first DLL loaded must be in Syspro's BASE\ManagedAssemblies folder. This is the one you configure when you create the custom pane (see screen shot below).
   
2. Then Syspro will look in its BASE directory, for all subsequent DLL's referenced by the first and subsequent DLL's; for those subsequent DLL's, Syspro WILL NOT look in the ManagedAssemblies directory. This is because Syspro doesn't have control over where subsequent DLL's are loaded from, so Windows tries to load them from the same folder that the Syspro client (IMPACT.EXE, IMPCSC.EXE, or SYSPRO.EXE) is run from. That directory is usually Syspro's BASE directory, NOT the ManagedAssemblies folder.
   
3. Windows will then look in the GAC.

This is problematic because Syspro only distributes DLL's in the ManagedAssemblies folder automatically from the server to all the Syspro clients; custom DLL's in the BASE directory will not be distributed by Syspro.

There are a number of ways to solve this:

1. Place your dependent DLL's in the BASE folder. This is the least-preferred option because you have to do it manually on each client PC.
   
2. Place your dependent DLL's in the GAC. Also not a preferred option.
   
3. Merge all your DLL's using ILMERGE, then place the merged DLL in the ManagedAssemblies folder.
   This works fine for WinForm-based applications, but won't work for WPF-based forms as ILMERGE can't merge all the WPF files.
   
4. Add some code to your first DLL, then place your dependent DLL's in the ManagedAssemblies folder.
   This is the recommended solution.
   See this post for details: http://support.syspro.com/forums/viewtopic.php?f=1&t=4603#p20524

How to find what DLL's are not being loaded

Now we get to the point of this post: HOW to find what DLL's have not been loaded.
The key is to run ProcMon: run a trace while you invoke the custom pane for the first time after starting Syspro.
Then use a reasonable filter such as shown in the screen shot below:

Then search the list and you may find what DLL has been missed, as shown in the screen shot below.

This method doesn't always seem to work, for reasons I don't yet know, but its the best method I know of to find the exact problem directly.

How to connect to a Syspro web service

Syspro has a very powerful and comprehensive set of API's exposed as web services. Here is a guide for how to use Syspro's web services.

Firstly, you need to connect to your Syspro web service’s server and get authenticated; in return, you will get a GUID.

To do this, you need to connect to the Logon method of this SOAP service:

http://example.com/sysprowebservices/utilities.asmx

Then you will can call an actual API to do something useful. In this example, we will send Syspro a finished goods receipt using the Transaction web service:

http://example.com/sysprowebservices/transaction.asmx

To call the Transaction web service, you need to pass these four parameters:

1. UserId – use the GUID you obtained when you logged into SYSPRO as described above.
2. BusinessObject – set it to be this string: INVTMR. There are many business objects that you can call via the Transaction web services; consult the Syspro business object documentation on the Syspro Support Zone for what web services you can use. 
3. XMLParameters – this will be a fairly large string containing an XML document as described below.
4. XMLIn – this will be a fairly large string containing an XML document; see below for example.

XMLParameters

Here is an example of the XMLParameters string:

<?xml version="1.0" encoding="Windows-1252"?>

<PostInvReceipts xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="INVTMR.XSD">

  <Parameters>

    <TransactionDate>2013-08-20</TransactionDate>

    <ApplyIfEntireDocumentValid>Y</ApplyIfEntireDocumentValid>

    <ValidateOnly>N</ValidateOnly>

    <ReturnDetailedReceipt>N</ReturnDetailedReceipt>

  </Parameters>

</PostInvReceipts>

XMLIn

Here is an example of the XMLIn string:

<?xml version="1.0" encoding="Windows-1252"?>

<PostInvReceipts xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="INVTMRDOC.XSD">

  <Item>

    <Warehouse>FG</Warehouse>

    <StockCode>A100</StockCode>

    <Quantity>1.000</Quantity>

    <Reference>Receipt</Reference>

  </Item>

</PostInvReceipts>

XMLOut

On successfully calling the web service, you should get a result like this:

<?xml version="1.0" encoding="Windows-1252"?>

<postinvreceipts Language='05' Language2='EN' CssStyle='' DecFormat='1' DateFormat='01' Role='01' Version='6.1.038' OperatorPrimaryRole='   '>

<Item>

<ItemNumber>000001</ItemNumber>

</Item>

<Key>

<JnlYear>2013</JnlYear>

<JnlMonth>05</JnlMonth>

<Journal>00032</Journal>

<EntryNumber>00001</EntryNumber>

<Warehouse>FG</Warehouse>

<GlJournal>

<GlYear>2013</GlYear>

<GlPeriod>05</GlPeriod>

<GlJournal>00230</GlJournal>

</GlJournal>

</Key>

<StatusOfItems>

<ItemsProcessed>1</ItemsProcessed>

<ItemsInvalid>0</ItemsInvalid>

</StatusOfItems>

</postinvreceipts>

XSD files

There are XSD files available for each Business Object. The XSD files are distributed with Syspro and found in the <Syspro-installation-directory>\Base\Schemas directory. These XSD files can be used to generate code objects. See this blog for more information on generating code objects from Syspro's XSD files: http://phildetail.blogspot.com.au/2014/04/how-to-use-xsd2code-for-syspros.html

What LOG files does Syspro create?

Diagnosing errors can be tricky; a log file can be invaluable. Here are some log files that Syspro updates.

Log file	Description
BASE/mfdebug.log	This file gets written to when you crash Syspro; you can crash Syspro by creating a custom with a .Net User Control that throws an unhandled exception.
BASE/SRSQRT.TXT	If you create an empty file, BASE/SRSQRT.DEBUG, file, then as soon as SRS or VBScriptiong with CALLBO is used, this log file will be written to.
BASE/log.txt	If you call SYSPRO.EXE, IMPACT.EXE, IMPCSC.EXE or IMPAUT.EXE with the /log parameter, then this file will be created. It will record each time the client/server communications dialog tries to connect to the server.
BASE/settings/<operator>_RTS_ERROR.TXT	Created when there is a runtime error.
%Temp%/SYSPROCOMMLOG_*.txt	Syspro Communications Service will log files in your Temp directory (e.g. C:\Users\You\Local Settings\Temp) if you have the DetailedLog setting set to true in your Syspro Communications Service's config file, e.g. <add key="DetailedLog" value="true" /> in C:\Syspro\Syspro WCF Services\SYSPROWCFHostService.exe.config.
%Temp%/SYSPROActivityCallsLog.txt	If you create this file, the Syspro Workflow engine will log actions in it.
BASE/Settings/enetlog.dat	This log file identifies the Business Objects invoked. This file gets written to by e.Net. There are two ways to cause this file to be written to: Set the LogLevel parameter to ldDebug when you use e.Net to log into Syspro. In the Syspro GUI, go to Setup / Setup Options / General Setup / System Setup; go to the General tab and set Diagnostics to enet01. BASE/Settings/enetlog.txt does not seem to be written to anymore, since about Syspro 6.1 SP1. To view enetlog.dat, go to Home / Administration / Diagnostics / Diagnostics Manager (aka. IMPMON). Then go to the e.net Transaction Log tab and hit the Refresh button. See this post for more details.
BASE/Settings/diag_xml	Xml inputs and outputs to Business Objects are logged here if the Diagnostics setting in System Setup / General is set to enetxx.
e.net Transaction Log	Go to Home / Administration / Diagnostics / Diagnostics Manager / e.net Transaction Log and hit the Refresh button.
AdmEventLog (database table)	Go to Home / Customzation / Event Management / Functions / View Log File.
AdmSignatureLog (database table)	Query this table directly in the database using SQL Server Management Studio or similar.
Job Logging	Go to Setup / Security / Job Logging. This listing includes program Logon and Logoff dates and times - quite useful.
Windows Event Log	Go to the Windows Event Log / Applications and Services Logs / SYSPROCOMMS and SYSPROSWS.
BASE\Settings\IMPUPD_Copy_Errors_*.txt	Errors encountered installing Syspro ports.
Electronic Signatures Audit Log	To view this, from the Syspro main menu, go to Program List / Administration / Electronic Signatures / eSignature Query.

Don't forget these invaluable tools as well:

• Windows Event Log
• Process Monitor
• SQL Server Profiler
• Sql Diff Framework - an awesome SQL data diff tool!
• APEX Sql Log - indispensible!
• Sql Log Analyzer
• IIS's log files
• Hawkeye
• Fiddler
• WireShark
• Fuslogvw - assembly binding log viewer
  This is a good guide for using Fuslogvw: http://larryparkerdotnet.wordpress.com/2011/08/02/net-fusion-log-viewer-101/

Eight things every developer needs to know about SYSPRO

Syspro is highly customisable and extendable using programs you can write in C# or VB.Net, VBScript, or using web services, workflows, you name it, but there are some key things you need to know about.

1. Where does Syspro run VBScripts?

Syspro has an in-built VBScript engine that allows Syspro administrators to add custom functionality on to Sypsro. There are a few things that are useful to know about SYSPRO's VBScript engine.Firstly, it's important to know where your VBScripts run: either on the server or on the client.

VBScripts as code behind forms

VBscripts that are placed in the code behind your forms run on the Syspro client; these are triggered from user-interface events such as a form's OnLoad event or a field's OnLostFocus event.

Electronic Signatures

VBScripts that are triggered from Syspro's Electronic Signatures are run on the Syspro server.

Event Management

Event Management events are executed on the server.

Trigger Programs

Trigger Programs run other Syspro programs, but do not fire VBScripts directly themselves. They run on the client.

2. What companies are affected by a VBScript?

When you install a VBScript in SYSPRO, it applies to all companies managed by that server.

This can trap unwary users! Be warned: even if you have a test company and a live company and you install your VBScript in the test company, it will affect the live company immediately!

The correct way to handle this is to have a totally separate SYSPRO server for development and testing.

Also, you can easily limit your VBScripts to a particular company with code that uses the Company system variable, such as this example, where "T" might be the company you use for your test company:

if SystemVariables.CodeObject.Company = "T" then

    <your code>

end if

or more simply:

if SystemVariables.CodeObject.Company <> "T" then exit function

3. What users are affected by a VBScript?

When you create a VBScript, that VBScript will not only affect all companies; it will also affect all users, not just the user that created the VBScript. In other words, the script is a system-wide VBScript.

However, if you are using Roles, you will have a choice whether to edit the system-wide VBScript, or to create or edit the VBScript that will just affect the users of that Role. This is the correct method to use to limit a VBScript to one or more users.

4. What users will see changes to a menu or pane?

If you move fields around on a pane, or change their Field Properties (font, colour etc.), then only the logged-in user will see those changes next time you log in again, and you will only see them on the same computer that you logged in on, i.e. if you log in on another computer as the same user, you won't see those changes. This is because the changes are recorded in local .DAT files; these files are not copied up to the server and distributed to other computers.

However, if you are using Roles, then all people in that role will see the changes. The changes are again stored in local .DAT files, but they are copied up to the server and distributed to other users of that role.

5. What users will see new custom or scripted fields?

If you create a new custom or scripted field and add it to a pane, all users will see it on their pane.

6. Where does Syspro run reports?

Syspro runs reports using SRS, aka. Syspro Reporting Services, which uses Crystal Reports at its core.
Custom-written reports are run on the Syspro CLIENT, in Syspro 6.1. This is the case, in Syspro 6.1, regardless of which communication method you are using: Syspro Communications Service (which is built using WCF) or the CCIT communications service.

I don't yet know where STANDARD (i.e. not custom-written) Syspro reports are run, although I suspect they're run on the client.

I suspect that in Syspro 7, reports will be run on the server, but this is yet to be confirmed.

7. Where does Syspro run Workflows?

Syspro workflows can be started by a VBScript on the Syspro client, but the workflow itself runs on the server.

8. What configuration files does Syspro use?

IMPWRK.INI

On the client, when you log in, the IMPWRK.INI file is first read from the same directory that the Syspro executable file is stored in. So if you run C:\Syspro61\BASE\IMPCSC.EXE, then the first configuration file read will be C:\Syspro61\BASE\IMPWRK.INI.

IMPACT.INI

IMPWRK.INI points to a second file, IMPACT.INI, which is usually kept in C:\Syspro61\WORK\IMPACT.INI.

Sysprodb database

Syspro keeps its data in Microsoft SQL Server a database, and it has a master database, SysproDb, that it uses to map each company to its database.

ADMOPR.DAT and other *.DAT (and their *.IDX) files

Syspro keeps its list of operators in the file, ADMOPR.DAT and its associated index in ADMOPR.IDX. These two files are kept on the Syspro server, but they are copied down to the Syspro client when the client logs in.

Other .DAT files are copied to the Syspro client at log-in as well. See the tables below for more information.
The .DAT files are C-ISAM files.

Filename prior to and including Syspro 6.1	Where kept	Description	Where the information is kept in Syspro 7
ADMLSR.DAT (.idx)	Client	List view layouts and settings file	List_operator_listviewName.XML
ADMLSD.DAT (.idx)	Client	Docking control layouts	Dock­­_operator_dockingName.XML
ADMLST.DAT (.idx)	Client	Form settings	ADMLFR.DAT (.idx)
ADMPRO.DAT (.idx)	Client	Form caption sequences	Form_operator_formName.XML
ADMLAY.DAT(.idx)	Server	List view, docking, form and customized pane layouts for roles	…\settings\role_nnn\
			List_name.XML
			Form_name.XML
			Dock_name.XML
			Pane_name.TXT
ADMPRO.DAT (.idx)	Server	Group and Company caption layouts	Form_Group_group_formName.XML
			Form_Company_company_formName.XML
ADMOPR.DAT (.idx)	Server	List of Syspro Operators	ADMOPR.DAT (.idx)

How to configure SQL Server for SYSPRO

These instructions apply to SQL Server 2005 and later, including SQL Server 2008 R2, SQL Server 2012, and SQL Server Express versions.

Set Collation Order

The collation order for a SYSPRO database MUST be case-sensitive; the recommended collation order is Latin1_General-BIN. Normally you would set the database server's default collation to be this order, but you can set it at the individual database level by creating a new database and setting its collation order; you must do this BEFORE you get Syspro to populate the database with tables etc.

Set Mixed Authentication Mode

Your SQL Server should be set to SQL Server and Windows Authentication mode in your Server properties.

Database Usage

The Compatibility level of your database must be set to SQL Server 2005 or later; SQL Server 2000 is not supported by Syspro.

See this document for more details: SQL Server Tricks and Best Practices.pdf

Set Desktop Heap size on the server

If you have a large number of users, you should increase your desktop heap limit on the Syspro Application Server. See this post on the Syspro Forum for more details.