Find content
Hi
I've not personally tackled this problem before.
Is it possible to execute as part of logon to your pro-iv application a system command (something like ipconfig) on the client pc ... that outputs the results to a text file ... then acess this text file for the IP address.
There are commands CLIENT.Execute, CLIENT.Send, CLIENT.Receive which may be helpful in executing commands and file-handling on client pc.
I'll also chase one of my colleagues who may know more in this area.
Plus have you tried pro-iv support as they are generally helpful with such queries.
Hope this helps
George
Posts I've Made
In Topic: pro-iv record locking question
09 February 2012 - 10:22 AM
Hi
What database are you using ISAM, ORACLE ?
You have described that there is a screen function where a user can change records
AND
an update function that another user/session can delete the same records
The user in the screen is not going to have a good user experience, that records they have selected for processing in a paging screen are deleted at same time by another process/user.
A possible solution (I have used this in past)
re-design the screen function
a) in an update function load the selected keys and maybe some data fields into a workfile
perhaps you could set a value on the data record to show that this record is on-hold/selected for processing
(generally I'd record OPR id and process-function that has selected/held the data record)
use this file as the primary file in your paging screen and the user changes values on this file
c) on exit from the paging screen call an update to apply the changes captured.
Make sure that you remove the value that identifies the record(s) is being processed.
If the update finds that the data record(s) has been deleted (no longer present) then you could present the keys of the missing records on an error report/screen to the user.
you could also re-design the update function
a) read the table fist in Lookup mode and check the value on the data record that identifies if a record has been selected by another process - is lready seleced than DSEL.
Then read the table for a 2nd time in Delete Mode
Hope this helps
Rgds
George
What database are you using ISAM, ORACLE ?
You have described that there is a screen function where a user can change records
AND
an update function that another user/session can delete the same records
The user in the screen is not going to have a good user experience, that records they have selected for processing in a paging screen are deleted at same time by another process/user.
A possible solution (I have used this in past)
re-design the screen function
a) in an update function load the selected keys and maybe some data fields into a workfile
perhaps you could set a value on the data record to show that this record is on-hold/selected for processing
(generally I'd record OPR id and process-function that has selected/held the data record)
use this file as the primary file in your paging screen and the user changes values on this filec) on exit from the paging screen call an update to apply the changes captured.
Make sure that you remove the value that identifies the record(s) is being processed.
If the update finds that the data record(s) has been deleted (no longer present) then you could present the keys of the missing records on an error report/screen to the user.
you could also re-design the update function
a) read the table fist in Lookup mode and check the value on the data record that identifies if a record has been selected by another process - is lready seleced than DSEL.
Then read the table for a 2nd time in Delete Mode
Hope this helps
Rgds
George
In Topic: RECORD LENGTH REDUCED
12 October 2011 - 08:16 AM
Hi Rob
The following is the procedures that we follow if we encounter the RECORD LENGTH REDUCED in @F ....
a) run ischk filename.pro to check the integrity of the file.
Run iskeys filename.pro > FILENAME.TXT, in the header output is the "record length: nnnn".
If your record length is not 3000 (not > 1583 for your file), then apply the following
c) run "isout filename.seq filename.pro" creating seq file of the existing .pro file
d) run iscr -knn -r3000 to create the file with rec len of 3000
(record lenght is now > 1583 and will accomodate popualtion to max of all fields and allow for addition of more fields)
e) run isin filename.seq to re-populate the file with its original contents.
f) run ischk filename.pro to check the integrity of the file.
hope this helps
George
The following is the procedures that we follow if we encounter the RECORD LENGTH REDUCED in @F ....
a) run ischk filename.pro to check the integrity of the file.
Run iskeys filename.pro > FILENAME.TXT, in the header output is the "record length: nnnn". If your record length is not 3000 (not > 1583 for your file), then apply the following
c) run "isout filename.seq filename.pro" creating seq file of the existing .pro file
d) run iscr -knn -r3000 to create the file with rec len of 3000
(record lenght is now > 1583 and will accomodate popualtion to max of all fields and allow for addition of more fields)
e) run isin filename.seq to re-populate the file with its original contents.
f) run ischk filename.pro to check the integrity of the file.
hope this helps
George
