Jump to content


George Macken

Member Since 05 Jun 2001
Offline Last Active May 29 2013 08:30 AM
-----

Posts I've Made

In Topic: how to obtain the ip address in open client?

14 May 2013 - 09:44 AM

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

In Topic: Rebooting ProIV Server Nightly - Should We?

03 April 2012 - 01:17 PM

Hi Ross

"We have many users who don't log off correctly so restarting the kernel without rebooting is a good idea."

We have also encountered this problem of users not logging off, it was a very regular occurrence when we exposed the system to (wan, stunnel, vpn, etc), we implmented usage @TIMEOUT to log-out users after a period of inactivity and this made a big difference in reducing the occurrences.
Platform win2003, pro-iv 5.5 and oracle 9i, generally servers are not re-booted, occasionally the pro-iv service is stop/started to clear any rogue sessions/users.

Rgds

George

http://www.proivrc.c...h__1#entry19180

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)

B) 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

In Topic: Oracle Selection Issue

21 December 2011 - 09:34 AM

Hi Tom

Reports in Pro-IV are not my main area of expertise - but I've wrote a lot of them

In your report - if you rem out the sel-only in LS of ORDER_DTL does the report execute and return the all detail lines from the DTL table - place UMSG in the After REad of the DTL. ?

Assumin the report is to print 1 order only, I would typically code it as
LS1 (Assuming you are reading the HDR in this LS)
defined as ONE-TIME = 'Y'

LS1 - Default LGC
ORDER_HDR_ID = some value passed into the report function


LS2 (Assuming you are reading the DTL in this LS)
defined as ONE-TIME = 'N'
LS2 - Default LGC
* ORDER_HDR_ID this value inherited from LS1
ORDER_HDR_LINE = ''
SEL-ONLY( ORDER_HDR_ID )

The FLDs of LS1 should encompass the fields of LS2

If you post attachements/prints of your functions and the 2 Filedefs then I'm sure one of the many contributors to this forum will help you out.

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.
B) 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