Clarion - HELP!! CLW4: Another question about 'Assertion failed after COMMIT'

Author

HELP!! CLW4: Another question about 'Assertion failed after COMMIT'

fesierra

2006-09-04, 6:55 pm

Hi:

I have an APP running over a small microsoft network (4 Windows ME
machines).
I am using TopSpeed driver. CLW 4b. The check for 'Enclose RI code
inside transaction frame' is on.

When updating a record (using edit in-place) I get occasionally this:
'Assertion failed in line 1209 in ABFILE.CLW'

Problem is an errorcode after COMMIT (I don't know the code.. this
error
is being hit inside the relation manager procedure, which is generated
and I dont want to touch).

TOPSPEED.TCF file is local to each workstation, so I don't think it has
anything to do with permissions to the file. (I know it is better to
have only one for all the network but I just discovered this when
browsing the manuals looking for an explanation to the error).

My questions are:

Is this error only an annoyance or has it potential to corrupt the data
files? The APP uses
a dictionary with 11 TPS tables in separate files. The procedure that
triggers the message is a simple update of a children record which does
not change key fields.

Is it possible to disable the 'Enclose RI code inside transaction
frame' without putting
the data at greater risk? My understanding is that there are file
drivers, such as DBF
which do not support transaction frames and still can run apps over a
network.

Any help would be greatly appreciated

Federico

Robert Peros

2006-09-06, 7:55 am

"fesierra" <fesierra@hotmail.com> wrote in message
> I have an APP running over a small microsoft network (4 Windows ME
> machines).
> I am using TopSpeed driver. CLW 4b. The check for 'Enclose RI code
> inside transaction frame' is on.
And "off" for Aliased File, if are used?

> When updating a record (using edit in-place) I get occasionally this:
> 'Assertion failed in line 1209 in ABFILE.CLW'
And no else in network, not work in same record.
And what Assert exactly say in your version of AbFile.clw/source code?
Is it the same if you use classic update form.?

> Problem is an errorcode after COMMIT (I don't know the code.. this
File date are good updated,even error is popup?<cut>

> Is this error only an annoyance or has it potential to corrupt the data
> files? The APP uses
> a dictionary with 11 TPS tables in separate files. The procedure that
> triggers the message is a simple update of a children record which does
> not change key fields.

> Is it possible to disable the 'Enclose RI code inside transaction
> frame' without putting> the data at greater risk?
No,w/o RI(Logout) you file operation speed are slowly(implicite risk),
power failure in the middle of long file operation are not secure,
nonconsistent data,etc.

> My understanding is that there are file> drivers, such as DBF
> which do not support transaction frames and still can run apps over a
> network.
Yes, this is Ok,but can't be mixed different drives in one RI transaction.

R.

fesierra

2006-09-06, 6:55 pm

Robert Peros wrote:
> "fesierra" <fesierra@hotmail.com> wrote in message
> And "off" for Aliased File, if are used?

No aliased files.

> And no else in network, not work in same record.

Two more users working on the same file but different records.

The problem is not so severe when there are only 2 users working.. it
may appear
once during a capture session.. but if a third user starts working, it
becomes
pretty annoying.

> And what Assert exactly say in your version of AbFile.clw/source code?

I don't have my Clarion here... I can give you that info in a few
hours.

> Is it the same if you use classic update form.?

Only one field is being updated, so no classic update form is being
used.. just a quick capture-down arrow key. (It is a program to capture
multiple choice school test answers). So it is a header-detail form,
where the details are the answers to the test and the header is used to
store totals. No totals are calculated at capture time. A different
procedure is used to do that (it is a loop procedure which goes through
every answer and
comparing to a template. I am not using LOGOUT here.. I am using STREAM
to
lock the file while the loop works).

> File date are good updated,even error is popup?<cut>
>

To be honest I have not noticed because after the message, the app
crashes and
the user has to run it again. So they go back to their form and
recapture but I
have not paid enough atention to see where exactly were they capturing
to see
if the record was correctly updated.

>
> No,w/o RI(Logout) you file operation speed are slowly(implicite risk),
> power failure in the middle of long file operation are not secure,
> nonconsistent data,etc.

Ok so Transaction frame stays there.

>
> Yes, this is Ok,but can't be mixed different drives in one RI transaction.
>
> R.

Thanks for you response. I really appreciate it. I have some

users here.

Federico

fesierra

2006-09-07, 3:55 am

fesierra ha escrito:

> Robert Peros wrote:
>

This is the procedure code. The last ASSERT before the CheckError
routine is
the one that is failing. Maybe the relations manager is getting

?. The procedure
in my APP that triggers the error is a browse with edit-in place, which
is inside a form
called from a browse, which is inside of another form. These are called
from yet another
browse inside another form. May seem like too many levels but I would
think that
Clarion can handle this and more.. maybe I was just naive.

RelationManager.Update PROCEDURE(BYTE FromForm)
RetVal BYTE(Level:Benign)
I LONG,AUTO
CODE
RetVal = SELF.Open()
DO CheckError
IF SELF.UseLogout
RetVal = SELF.LogoutUpdate()
DO CheckError
LOGOUT(2)
END
IF SELF.Me.UpdateServer(1+FromForm)
IF SELF.UseLogout
ROLLBACK
END
IF SELF.Me.Info.LastError = Msg:ConcurrencyFailed OR
SELF.Me.Info.LastError = Msg:ConcurrencyFailedFromForm
RetVal = Level:Notify
ELSE
RetVal = Level:User
END
DO CheckError
END
LOOP I = 1 TO RECORDS(SELF.Relations)
GET(SELF.Relations,I)
IF SELF.Relations.UpdateMode AND NOT
SELF.Relations.Fields.EqualLeftBuffer()
RetVal =
SELF.Relations.File.UpdateSecondary(SELF.Relations.HisKey,SELF.Relations.Fields,SELF.Relations.UpdateMode)
IF RetVal
SELF.Relations.Fields.AssignRightToLeft
DO CheckError
END
END
END
IF SELF.UseLogout
COMMIT
ASSERT(~ERRORCODE())
END
SELF.Close
RETURN RetVal

CheckError ROUTINE
IF RetVal
SELF.Close
RETURN RetVal
END

Robert Peros

2006-09-07, 7:55 am

"fesierra" <fesierra@hotmail.com> wrote in message
> This is the procedure code. The last ASSERT before the CheckError
> routine is > the one that is failing. Maybe the relations manager is getting
>

?.<cut>
Maybe,but LOGOUT is system(driver) state,specialy if network use one
tcf(transaction control file) for a system,and is pretty stable.

From your second post" I am not using LOGOUT here.. I am using
STREAM lock the file while the loop works".

FLUSH(..) like implicite unlock, at end STREAM-ing file,because:
"A variety of data files have been tested extensively for corruption,
and at this time only one problem has been identified with the file driver.
This data corruption occurs if the following code is issued:
STREAM(file)
LOGOUT(1,file)
ROLLBACK"

For the test purpose add AssertCode for check which error are
generated.Basicly for COMMIT you have 2 errors
48 Unable to Log Transaction
91 No Logout Active

> RelationManager.Update PROCEDURE(BYTE FromForm)
<cut untouched >

> IF SELF.UseLogout
> COMMIT
> ASSERT(~ERRORCODE())
? ASSERT(~ERRORCODE(),ERRORCODE() & ' Commit err. in '
& 'RM.UpdateromForm' & THREAD())
<cut untouched >

> CheckError ROUTINE
> IF RetVal
IF SELF.UseLogout AND SELF.Me.File{PROP:Logout}
MESSAGE('CheckError ' & 'RM.' & THREAD())
!ToDo ROLLBACK() !Yet blocked by COMMIT
END
<cut untouched >

R.

fesierra

2006-09-11, 6:55 pm

Robert:

Thanks for your posting. I tried to put the TCF file in a shared
network folder and
last time I checked, the file was not where I set it up to be. So I
might just first
try to fix that (putting the TCF file as common for the network) and
see if things
improve with that. I tried declaring a string where I stored the
location of the
TCF file and using it in the driver options panel for the file in the
DCT editor. It
does not seem to be working. I will try to find out the correct way to
set it.

Thanks. I will keep you informed of the progress.

Federico

Robert Peros wrote:
> "fesierra" <fesierra@hotmail.com> wrote in message
> Maybe,but LOGOUT is system(driver) state,specialy if network use one
> tcf(transaction control file) for a system,and is pretty stable.
>
> From your second post" I am not using LOGOUT here.. I am using
> STREAM lock the file while the loop works".
>
> FLUSH(..) like implicite unlock, at end STREAM-ing file,because:
> "A variety of data files have been tested extensively for corruption,
> and at this time only one problem has been identified with the file driver.
> This data corruption occurs if the following code is issued:
> STREAM(file)
> LOGOUT(1,file)
> ROLLBACK"
>
> For the test purpose add AssertCode for check which error are
> generated.Basicly for COMMIT you have 2 errors
> 48 Unable to Log Transaction
> 91 No Logout Active
>
> <cut untouched >
>
> ? ASSERT(~ERRORCODE(),ERRORCODE() & ' Commit err. in '
> & 'RM.UpdateromForm' & THREAD())
> <cut untouched >
>
> IF SELF.UseLogout AND SELF.Me.File{PROP:Logout}
> MESSAGE('CheckError ' & 'RM.' & THREAD())
> !ToDo ROLLBACK() !Yet blocked by COMMIT
> END
> <cut untouched >
>
> R.

jonwaterhouse@gov.nl.ca

2006-09-12, 6:55 pm

STREAM is inherently a single-user process. As Robert points out it
should not be used in conjunction with LOGOUT/COMMIT. In general you
get the same speed advantages from logout/commit as you do from STREAM.
I'd dump STREAM and see if that solves your problem.

fesierra wrote:[color=darkred]
> Robert:
>
> Thanks for your posting. I tried to put the TCF file in a shared
> network folder and
> last time I checked, the file was not where I set it up to be. So I
> might just first
> try to fix that (putting the TCF file as common for the network) and
> see if things
> improve with that. I tried declaring a string where I stored the
> location of the
> TCF file and using it in the driver options panel for the file in the
> DCT editor. It
> does not seem to be working. I will try to find out the correct way to
> set it.
>
> Thanks. I will keep you informed of the progress.
>
> Federico
>
>
> Robert Peros wrote:

fesierra

2006-09-13, 6:55 pm

Thanks! I'll give that a try too.

jonwaterhouse@gov.nl.ca wrote:
> STREAM is inherently a single-user process. As Robert points out it
> should not be used in conjunction with LOGOUT/COMMIT. In general you
> get the same speed advantages from logout/commit as you do from STREAM.
> I'd dump STREAM and see if that solves your problem.
>

Sponsored Links