adding users (and a lot of field security) is causing crossing Progress boundaries

[Chris Kelleher]

This problem is occurring at one of our customers site (MXP 8.1C):

Starting SO 4 1 (SO Entry) from the menu is taking over 15 seconds before
the screen is shown. Debugging made it clear that this wasn't the SO entry
program. We noticed that a lot of field (and button) security is causing
probase to become very slow.

Since today we cannot start the function anymore. A progress error "**
Attempt to expand record beyond the maximum allowed size. (444)" occurs.
At first I thought that this error was caused by too many field security
entries, but
this didn't seem to be the case. The only difference in the data was that
about 20 extra users were set up via user maintenance (not increasing the
number of concurrent
users in the database, though).

By deleting these users the problem was solved.

Does this ring a bell to anyone?

If so, please let me know.

Regards,

Staf Fransen
Axias BV

 

[Chris Kelleher]

I would do and 'index rebuild' on this database, to re-initialize the
internal pointers. User in the database has very small impact with the
actual function running. Also you might want to make sure that you look at
the file 'z_pass' for an overload of security on a lot of user.

Serge Gariepy
Foresight Software

-----Original Message-----
From: Staf Fransen [mailto:fransen@axias.com]
Sent: Thursday, October 07, 1999 20:28
To: mxp@peg.com
Subject: adding users (and a lot of field security) is causing crossing
Progress boundaries

This problem is occurring at one of our customers site (MXP 8.1C):

Starting SO 4 1 (SO Entry) from the menu is taking over 15 seconds before
the screen is shown. Debugging made it clear that this wasn't the SO entry
program. We noticed that a lot of field (and button) security is causing
probase to become very slow.

Since today we cannot start the function anymore. A progress error "**
Attempt to expand record beyond the maximum allowed size. (444)" occurs.
At first I thought that this error was caused by too many field security
entries, but
this didn't seem to be the case. The only difference in the data was that
about 20 extra users were set up via user maintenance (not increasing the
number of concurrent
users in the database, though).

By deleting these users the problem was solved.

Does this ring a bell to anyone?

If so, please let me know.

Regards,

Staf Fransen
Axias BV

 

[Chris Kelleher]

The index re-build makes no difference. I've had a look at z_pass but the
largest number of entries in the security field is 25. Deleting the users
works around the problem, but it's strange that only SO 4 1 falls over.
Maybe it's some kind of combination of user ids and z_pass setup? Also we've
been able to generate the same error message by stuffing a large amount of
data into a single variable, so it's not necessary a DB table update that's
causing the problem.

Gordon Robertson
BSkyB

-----Original Message-----
From: Serge Gariepy
[mailto:Serge.Gariepy@foresight-esp.com]
Sent: 11 October 1999 14:01
To: mxp@peg.com
Subject: RE: adding users (and a lot of field
security) is causing crossin g Progress boundaries

I would do and 'index rebuild' on this database, to
re-initialize the
internal pointers. User in the database has very small
impact with the
actual function running. Also you might want to make sure
that you look at
the file 'z_pass' for an overload of security on a lot of
user.

Serge Gariepy
Foresight Software

-----Original Message-----
From: Staf Fransen [mailto:fransen@axias.com]
Sent: Thursday, October 07, 1999 20:28
To: mxp@peg.com
Subject: adding users (and a lot of field security) is
causing crossing
Progress boundaries

This problem is occurring at one of our customers site (MXP
8.1C):

Starting SO 4 1 (SO Entry) from the menu is taking over 15
seconds before
the screen is shown. Debugging made it clear that this
wasn't the SO entry
program. We noticed that a lot of field (and button)
security is causing
probase to become very slow.

Since today we cannot start the function anymore. A progress
error "**
Attempt to expand record beyond the maximum allowed size.
(444)" occurs.
At first I thought that this error was caused by too many
field security
entries, but
this didn't seem to be the case. The only difference in the
data was that
about 20 extra users were set up via user maintenance (not
increasing the
number of concurrent
users in the database, though).

By deleting these users the problem was solved.

Does this ring a bell to anyone?

If so, please let me know.

Regards,

Staf Fransen
Axias BV

 

[Chris Kelleher]

Folks,

Variables are internally stored as temp-table fields -
the following assignment causes error 444 (v9.0a):

DEF VAR x AS CHAR.
x = FILL ("x", 32000).

Frank