- ProIV Resource Centre
- → Viewing Profile: Posts: Mike Schoen
Community Stats
- Group Members
- Active Posts 198
- Profile Views 6,840
- Member Title Expert
- Age Age Unknown
- Birthday Birthday Unknown
-
Gender
Male
-
Location
Guelph, Canada
Previous Fields
-
First Name
Mike
-
Surname
Schoen
-
Year Started ProIV
1990
-
Highest ProIV Version Used
5.5
-
Company Working For
Texada Software
0
Neutral
User Tools
Friends
Mike Schoen hasn't added any friends yet.
Latest Visitors
Posts I've Made
In Topic: ProIV & SQL Server 2005
18 October 2007 - 12:59 PM
We have just done some testing with the latest 5.5 release and sql 2005 express, and have found the following deadlock issue.
This is done using a pro-iv non-paging screen, with one file in change mode, and no full-function sql - ie a plain pro-iv function.
Session 1 reads a record in change mode
Session 2 tries to read the same record, and gets a record lock, waiting for file
Session 1 accepts the changes by entering through the screen, and gets a deadlock rollback.
Session 2 then gets the record, and can carry on and save it's changes.
Very strange, if we get a resolution to this, I will post it here.
This is done using a pro-iv non-paging screen, with one file in change mode, and no full-function sql - ie a plain pro-iv function.
Session 1 reads a record in change mode
Session 2 tries to read the same record, and gets a record lock, waiting for file
Session 1 accepts the changes by entering through the screen, and gets a deadlock rollback.
Session 2 then gets the record, and can carry on and save it's changes.
Very strange, if we get a resolution to this, I will post it here.
In Topic: Evaluation license
03 July 2007 - 01:49 PM
Yes, this is how eval mode works. I am not 100% sure, but I believe that you will get logged out after 2 hours, and that the loggout happens on user input, or when changing functions.
In Topic: Oracle error ORA-12516
11 April 2007 - 05:49 PM
Have you tried doing a SQL trace of the function?
If you remove the UMSG for your specific login, and enable tracing, this may give you a sql statement trace up to the point of death. Trace files are a bit of a bear, but you can at least see the sql pro-iv is issuing before it dies.
if you are on a windows application server, I dont know how to turn on tracing for one session, so you may need to do this after-hours.
For a unix application server,
export TR_PATH=/tmp/myfile.trace
export TRACESQL=8
export TRACEGEN=3
This will give you a detailed tracefile of the sql statements. The TRACEGEN should give you a trace of function/global functions as they are loaded, so that you can narrow down the code section.
Mike
If you remove the UMSG for your specific login, and enable tracing, this may give you a sql statement trace up to the point of death. Trace files are a bit of a bear, but you can at least see the sql pro-iv is issuing before it dies.
if you are on a windows application server, I dont know how to turn on tracing for one session, so you may need to do this after-hours.
For a unix application server,
export TR_PATH=/tmp/myfile.trace
export TRACESQL=8
export TRACEGEN=3
This will give you a detailed tracefile of the sql statements. The TRACEGEN should give you a trace of function/global functions as they are loaded, so that you can narrow down the code section.
Mike
In Topic: PRO IV VIP 5.5 - Errors while Bulk Loading
13 March 2007 - 01:16 PM
VIP is far more strict in what you can get away with.
Non-contiguous cycles would be something like:
LS 1 fields 1 to 10
LS 2 field 1 to 12
LS 3 fields 4 to 10
Duplicate tags: check the field and header tags, there are duplicates.
I haven't seen the cycle reference 00 before, all I can think of is that its a lscall or winopen statement.
This will all have to be done in @STUDIO or @MOD in your 5.5 native area, and then re-loaded.
Mike
Non-contiguous cycles would be something like:
LS 1 fields 1 to 10
LS 2 field 1 to 12
LS 3 fields 4 to 10
Duplicate tags: check the field and header tags, there are duplicates.
I haven't seen the cycle reference 00 before, all I can think of is that its a lscall or winopen statement.
This will all have to be done in @STUDIO or @MOD in your 5.5 native area, and then re-loaded.
Mike
In Topic: SQL Server and Cursors
13 March 2007 - 01:06 PM
Neil,
The only suggestion I have is that you chech the functions called for commits, and try commenting them out in a test environment to confirm that the cursors really dont get closed.
We ran into this with sql 2000, and had to restructure a few functions to deal with losing cursors on commit.
We are doing testing on sql 2005 as well, to confirm that we are able to work with it despite its "not supported with release 5.5" status.
If we run into anything like this and can solve it, I will let you know.
Mike
Thanks Mike. Will scratch around a bit. Strange thing is that this set of boots was ported from a set of Oracle boots, where the only change has been the file defs. And it works 100% under Oracle![]()
We had the exact same surprise when we added mssql support to our application.
That and sub-selects caused a few rewrites

- ProIV Resource Centre
- → Viewing Profile: Posts: Mike Schoen
- Privacy Policy