Jim
 
I know this may sound silly but I would make sure that the tables or views that you base your temp views/tables on actually exist before defining those temp tables/views.
 
When you create your temp views make sure they are created only for the situation at hand thereby reducing memory usage (and temp file size) down to a minimum. Removing temp table/view when closing form is good.
 
I have found that 9.1-64 has been the best at handling memory with virtually no memory crashes. As Razzak says "stay current".
 
Hope this helps.
 
Bill Eyring
 
-------- Original Message --------
Subject: [RBASE-L] - Re: I/O problems
From: "Jim Belisle" <[email protected]>
Date: Wed, February 15, 2012 5:15 am
To: [email protected] (RBASE-L Mailing List)

Bill,



Thanks for the suggestion. I always use a "t" in front of the temp table
name but never did that for the columns.

I can see the wisdom in that procedure.



I did find the offending tables that were giving me the illegal table
error when I did my unload/load procedure.

As RAZZAK would say, I now have a good clean database (as far as no
errors when reloading).



I do not think I have licked the I/O problem yet.

The scratch files seem to grow pretty fast when I am in the explorer
mode.



Is there a way to clear those files without getting in and out of the
DB?

I drop my temp views and tables when closing forms or after a report has
printed.

Do you have any other suggestions?



James Belisle



Making Information Systems People Friendly Since 1990





________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, February 14, 2012 11:32 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: I/O problems



Jim,



You may have heard this and maybe not. When you create/re-create a view
sometimes the underlying schema has changed. This creates problems. I
don't believe in coincidences - if your problems started with the view
creation, then you have to look there.



Have you checked the underlying tables to make sure the schema hasn't
changed or make sure your definitions coincide with the underlying
schema ?



Instead of a view I might try a temp table avoid using exiting colimn
names. When I create a temp table I always try to use a "t" prefix for
the column name to prevent any possible column name duplicatio.



Hope this helps.



Bill Eyring





-------- Original Message --------
Subject: [RBASE-L] - Re: I/O problems
From: "Jim Belisle" <[email protected]>
Date: Tue, February 14, 2012 8:20 am
To: [email protected] (RBASE-L Mailing List)

Dan,

I have done the Unload/Load process several times since this
started
showing up and not until this morning did I get any error
messages.
Since I did get one this morning, I will have to do a TRACE to
find
where the offending table is sometime tonight.

I am not convinced that is the problem. The illegal table name
may be
the result of RBASE "hanging" because of the I/O problem. Since
this is
the first time I got an error and since I have rebuilt the DB a
few
times since this started, I do not think that is the problem.

This started around the time I started creating a View for a new
parts
allocation system. Any time I get into the form more than a
couple of
times in the DB explorer mode, (without getting out of RBASE
completely)
the system gives me this error. I would think it has something
to do
with the views created in the form.

This code creates the temp table.
CREATE TEMP TABLE topenorder (control# TEXT (9), dateprom DATE,
+
distname TEXT (25), shipname TEXT (25), shipnotes NOTE)
INSERT INTO topenorder SELECT control#, dateprom, distname,
shipname,
shipnotes FROM orderheader WHERE creditok = 'Y' AND control# IN
+
(SELECT DISTINCT control# FROM orderpartsneed)

This is the form I just created a few months ago when this
started.
BROWSE USING kpropackview

This is the view created on after start EEP.
CREATE TEMP VIEW tinvallopen +
(partnum, invpcs, alocatepcs, availpcs, madepcs, outpcs,
openpcs, vfont)
AS SELECT partnum, invpcs, alocatepcs, availpcs, madepcs,
outpcs,
openpcs, (IFLT(availpcs,0,'RED','BLACK')) +
FROM Inv_all_open WHERE Partnum IN (SELECT Partnum FROM
OrderPartsNeed
WHERE Model# = .vModchoice)

It seems rather simple to me and I can't see why it would cause
a
problem.

James Belisle

Making Information Systems People Friendly Since 1990


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Dan
Goldberg
Sent: Tuesday, February 14, 2012 8:28 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: I/O problems

Have you checked your database for errors?

Dan Goldberg

-----Original Message-----
From: Jim Belisle
Sent: Monday, February 13, 2012 7:21 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - I/O problems

I mentioned this a few weeks ago but still have not been able to
find
out why I am getting this I/O error.



Here is what I have done so far.

1) I looked and found only one rbengine76.CFG file

2) I changed my scratch settings to C:\TEMP form my local
settings
(C:\Documents and Settings\jim\Local Settings\Temp) and that did
not
help.

3) I clear my scratch files each time I start a session and that
clears them out. Most of those files also clear out when I exit
RBASE.



The time that I get this error most is when I am in the explorer
mode
and am testing new forms.

Is there anything else someone can point to that may help me
figure out
why this is happening?



James Belisle



Making Information Systems People Friendly Since 1990



Reply via email to