Ross Bevin

Hi Rob,

 

Thanks for the information. No, we run on Windows which I think is OK for Python. I will get one of our .NET developers to take a look.

 

Thanks

Ross

Hi Stef,

 

The maximum ProISAM record size is now -r16000 with a maximum file size of 1.9 GB. We started using this size in version 7. See help topic 720111 in the 8.2.9.58 online documentation.

 

Regards

Ross

Hi Joy,

 

It's quite simple. This is what I would do for each file.

 

1. Copy the ProISAM ProIV filedef to a file with say a small 's' appended to the name. E.g. GL_MSTR to GL_MSTRs.

2. In the file definition header change GL_MSTRs to file type SQLSERVE. Set the physical name as GL_MSTR. You will also have to go into the storage tab and set the Ext Type, format and alternate name for each field. Alpha fields are ALPHA and numeric fields are NUMBER. For NUMBER the format is <total field length including precision>.<precision>. If the number can be a negative append the format with an "S". E.g. S8.2 (can store a max of 999999.99-)

3. In the file definition window use the SQL icons to create and save the script to a text file for GL_MSTRs.

4. In SQL Server Management Studio open the script previously created and execute it in the right database to create the table.

5. Create an update function that reads all of GL_MSTR in look mode and adds to GL_MSTRs in add mode.

6. Delete file definition GL_MSTR.

7. Rename file definition GL_MSTRs as GL_MSTR.

8. Regen functions that use GL_MSTR.

 

You will need to update your c:\windows\pro4v8.ini file with the appropriate SQL database settings. You will also need to create an ODBC driver on the server that has the ProIV kernel; it needs to point to the SQL Server database.

 

When I did this for our system in 2003 I automated the process by writing a series of functions that used the filedef bootstrap files to create one SQL table creation script file. I also wrote a function that automated the file renaming. If your system is large you may want to consider this route.

 

A word of caution with moving to SQL Server. Depending on how your system is written/structured you may encounter a lot of table locking. This is especially true for control files where you say get the next available invoice number. In ProISAM you can have a logical update that gets and increments the number. After the record is written it is unlocked and other sessions can read and update it. This is not true for SQL tables. Typically you will have to either exit the function to commit the records or execute a commit command in logic. Executing the commit command can have unwanted consequences with other tables you are processing. Because of this we continue to maintain our control files in ProISAM.

 

Hope this helps!

 

Regards

Ross

Hi Richard,

Yes you are right, SSO's have a huge potential to expand the functionality of the ProIV environment. What's really great is that Northgate is using internal Java talent to develop core SSO's to provide solutions we have all been crying out for years. I just don't have the time to learn Java to develop these solutions. It's much more cost effective for us to purchase them off the shelf. ProIV 7.1 (I think 6.2 as well) comes with the following free SSO's:

EmailSSO
LDAPManager
SSOHTTP
SimpleMathsDemo

Available for purchase are: (You can request demo versions from Northgate to evaluate. They come with demo functions and HTML help files)

WordSSO
ExcelSSO
PdfSSO

I have just been demoing the PdfSSO but will be purchasing it later this week. This SSO uses (interfaces with) a 3rd party API from iTextPDF that does the PDF creation. There is a small licensing fee for iTextPDF if you use it commercially. The list of features I published was listed in the installation document.

The other SSO we have purchased is the ExcelSSO. We currently use Dynamic Data Exchange (DDE) to create Excel documents on the Client side; it has it's pluses and minuses. The bigest drawback with DDE is that it takes time to populate the spreadsheet, the user can't do anything while it's building and you can't build it behind the scenes. We are in the process of transitioning to the ExcelSSO so that we can build, save and distribute Excel spreadsheets on the server side.

Regards
Ross