I have a recurring problem and cannot see the cause of it.

I am uploading or deleting data from 2 files - a lookup and it's related data file. Trouble is that when the upload/delete reaches a certain point, an OI error is displayed on the screen, when I close that, a Windows GPF window is displayed. The OI Engine is also shutdown. This means I have to reboot my machine and restart the process. Deleting from the origin file as I am uploading means I can restart the process from the point of breakdown, but once the data reaches around the same number of records processed, it falls over again. Same error messages, etc.

Is this a windows problem? Or is there a buffer somewhere that is being overused? I clear the OI buffers regularly within the programs with "FLUSH" & "GARBAGECOLLECT".

But +/- 60000 records is the max I can run and then I crash. I can only think that windows and OI clash somwhere.

Any assistance would be greatly appreciated.

What operating system (Windows version) are you using?

If you post the code we may be able to suggest some options.

The Sprezzatura Group

World Leaders in all things RevSoft

The machines I run the system on are a mixture of '95 & '98 machines connected to an NT-Server.

Sample of Code:

This is a stored procedure. Information is retrieved from the screen, relevant tables are opened and then the data is retrieved:

*——————————————————————-

GET_RECORDS:

FLUSH

GARBAGECOLLECT

ClearSelect

Search='

call UTL_SELECT_ROWS('MAILING_DUPS2',Search,'','','')

RecCount=@RecCount

*print function, for a hardcopy report

      Stage=MAILINGS '

Recs=Selected: ':@RecCount

gosub PRINT_LINE

*screen display for monitoring progress

MsgTxt=De-duplicating Mailings'

RetVal=Set_Property(@Window:'.MESSAGES','TEXT',MsgTxt)

gosub READ_DUP_RECORDS

RETURN

*——————————————————————–

READ_DUP_RECORDS:

MastID		= ''

DupID		= ''

lCounter 	= 0

FCount		= 0

Done 		= 0

Loop

	ReadNext ID then

		MailDupRow=obj_xlate_row('MAILING_DUPS2',ID,'','X')

		lcounter += 1

		RecCount -= 1

		IDRec='

		MsgTxt=Records left: ': RECCOUNT

		RetVal=Set_Property(@Window:'.MESSAGES3','TEXT',MsgTxt)

		If MailDupRow then

			NoDups=Count(MailDupRow,@VM) + 1

			ErrFlag='

			If NoDups ] 1 then

				For DupCount=1 to NoDups

					ChkID=MailDupRow

					CustLookRow=obj_xlate_row('CUSTOMER_LOOKUP',ChkID,'','X')

					Table=CustLookRow

					If Table=CAMPAIGN_MAILINGS" else

						IdRec=DupCount

						DupCount=NoDups + 1

					End

				next DupCount

				IF IdRec=' then

					IdRec=1

				End

			end

		end

		If MailDupRow then

			MastID=MailDupRow

			NoDups=Count(MailDupRow,@VM) + 1

			If NoDups ] 1 then

				For DupCount=1 to NoDups

					If DupCount=IDRec else

						DupID=MailDupRow

						ErrFlag='

						gosub UPDATE_FILES	

						dCount += 1

						MsgTxt=dCount

						RetVal=Set_Property(@Window:'.MESSAGES2','TEXT',MsgTxt)

					end

				Next DupCount

			End

			if ErrFlag else

				@File_Error='

				Delete MailDupTable, ID else

					call OBJ_FILE_ERROR(FileError)

					call UTL_MSG_DISP(FileError:' - Cannot delete  row : ':ID)

				end

			end

		end

• check counter

		if DupTot then

			if lCounter=DupTot then

				If Recur then

					gosub GET_RECORDS

				end else

					Done=1

				end

			end

		end

• check flush

		FCount += 1

		if FCount=1000 then

			FLUSH

			GARBAGECOLLECT

			FCount=0

		end

	end else

		Done=1

	end

Until Done Repeat

RetVal=Utility('CURSOR','A')

MsgTxt=Completed : ': @RECCOUNT:' Records'

RetVal=Set_Property(@Window:'.MESSAGES','TEXT',MsgTxt)

Stage=Stage 2 COMPLETE'

Recs =Updated : ':lCounter

gosub PRINT_LINE

RETURN

*————————————————————————-*

UPDATE_FILES:

CT=Count(MailDupRow,@vm) + 1

for cx=1 to CT

	if LEN(MailDupRow) then

		CampCode=MailDupRow

		gosub CAMPAIGN_MAILINGS

	end

next cx

gosub CUSTOMER_LOOKUP

RETURN

*————————————————————————-*

CAMPAIGN_MAILINGS:

CTempID='

TempRow='

OldKey=CampCode:'*':DupID

CampOK=RowExists("CAMPAIGN_MAILINGS",OldKey)

if CampOK then

	Read CampRow from CampMailTable, OldKey then

		CTempID=CampRow

		If CTempID then

			TempRow=MastID

			@File_Error='

			Write TempRow on TempIDTable, CTempID else

				call OBJ_WRITE_ERROR('TEMP_ID',CTempID)

				ErrFlag=1'

			end

		end	

		@File_Error='

		Delete CampMailTable, OldKey else

			call OBJ_FILE_ERROR(FileError)

			call UTL_MSG_DISP(FileError:' - Cannot delete  row : ':OldKey)

			ErrFlag=1'

		end

	end

end

RETURN

*————————————————————————-*

CUSTOMER_LOOKUP:

OldKey=DupID 

Read CLookRow from CustLookTable, OldKey then

	Table=CLookRow

	If Table=CAMPAIGN_MAILINGS' then

		@File_Error='

		Delete CustLookTable, OldKey else

			call OBJ_FILE_ERROR(FileError)

			call UTL_MSG_DISP(FileError:' - Cannot delete  row : ':OldKey)

			ErrFlag=1'

		end

	end

end

RETURN

*——————————————————————-

The Windows erro reads like this:

"OENGINE caused a general protection fault in module OENGINE.EXE at 0003:000c308."

Of any help?

OK - educated guesswork time - using a process of

elimination. Faced with this code and your unusual

problem we might try the following steps…

Make a copy of this program and edit the copy like this…

First, change the XLATE code to OPEN…READ….CLOSE

statements.

Second, remove all the window progress displays.

Third - comment out the the print_line functionality

(just to see what happens).

Fourth, bring any external routine code into this

one program (minimize the external calls).

Fifth, adjust the operating system parameters:-

attach a different printer, log in as administrator,

run the program from a local disk, drop screen

resolution to bare minimum (amazing how many dodgy

video drivers cause Windows conflicts), change file

handles settings, etc.

If the process runs for a long time you might want

to modify the select to only gather enough records

to display the fault.

Incremental faults have sometimes occurred when a

hardware resource runs out, usually memory, disk or

file handles.

Avoiding symbolics, XLATES, deeply nested programs and

printer functions (even as a temporary step) can

sometimes highlight the culprit. Sometimes changing the

report sequence will highlight corrupt record keys

which foul the select processor.

Another favourite technique is to test the file

by selecting it using a different (unindexed)

field to reveal any lurking GFEs.

Thanks for posting the code. We'll give it some

further inspection for structure during a quiet(er)

moment

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...