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)