Have you tried:
unload structure for TableA
unload structure for ViewA
Bernie Lis
----- Original Message -----
From: "Dennis McGrath" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, January 24, 2008 10:01 AM
Subject: [RBASE-L] - RE: How do I get rid of a DBF Table?? -Clarification
I asked for this years ago. Sure would be nice!
Actually and UNLOAD STRUCTUREA, AND UNLOAD STRUCTUREB would be fantastic.
These along with UNLOAD DATA, would provide 3 files which defined everything
the way we need it.
I'd like to be able to unload each structure separately.
UNLOAD TABLES
UNLOAD VIEWS
UNLOAD INDEXES
UNLOAD etc...
But the STRUCTUEA AND STRUCTUREB would be a step in the right direction
Dennis McGrath
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael
Sinclair
Sent: Thursday, January 24, 2008 7:07 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: How do I get rid of a DBF Table?? - Clarification
It worked!!!!!!!!
Do you think it would be a good idea to request an enhancement, ie an
unload command that can create 2 separate structure files 1 for tables,
views etc the second for indexes, key restraints, etc?
That way this process could be contained entirely within a command file
(remove the need to split the structure file in 2 parts).
Mike
John Minyo II wrote:
Mike,
In cases where you run the output containing UNLOAD ALL, which does
not finish or results in errors, and you are forced to separate the
structure and data into separate files, it is recommended that you
also split the structure file into two parts, separating the table
structure from the constraints and indexes. The reason is that UNLOAD
ALL places the database structure and data into the correct order in
which to be rebuilt. However using UNLOAD STRUCTURE and then UNLOAD
DATA, you are creating your constraints and "then" adding the data.
UNLOAD ALL order of output:
1. CHAR Settings
2. CURRENCY Settings
3. SCHEMA
4. TABLES
5. DATA
6. DATE Format
7. VIEWS
8. CONSTRAINTS and INDEXES - based on order of creation
9. USERS
10. PRIVILEGES
11. AUTONUM
12. COMMENTS
13. RULES
14. TRIGGERS
By splitting the structure output after the very last CREATE TABLE
command, and breaking the structure file into two parts, you are
"more" likely to have problems loading data where constraints already
exist, than adding constraints where data already exists.
Of course, this depends on the level of corruption errors you are
encountering and the integrity of your data.
John
At 09:26 PM 1/22/2008, you wrote:
Ok, I think I am getting there...I did the unload structure
first....and ran it, and the new empty database is perfect.
I tried unload all, and it started to work, but it stopped to
quickly. When I ran it, it bombed before the data base was complete.
Not sure why, but UNLOAD ALL does not seem to work on big databases
(Should UNLOAD ALL work??)
Now that I have read this email, I am trying the following...
CONNECT dbname
OUTPUT c:\dbname.str
UNLOAD STRUCTURE
OUTPUT SCREEN
OUTPUT c:\dbname.dat
UNLOAD DATA
OUTPUT SCREEN
c:
cd c:\rbnew
RUN c:\dbname.str
RUN c:\dbname.dat
RUN pray for a miracle.app
Do I have it right?
Mike
Emmitt Dove wrote:
I'm a proponent of building a new database from scratch. Here's what I
would do:
- connect to your existing database
- unload the structure to one file
- unload the data to another
- edit your structure file to assure all is in order or to correct any
errors
- now in a fresh R:BASE session in another folder, RUN your
structure file
then RUN your data file
The result will be a fresh database that should be free of any
corruption.
This method is superior to RELOAD in that the only commonality
between the
old and new databases are text files (structure and data).
Emmitt Dove
Manager, DairyPak Business Systems
Evergreen Packaging, Inc.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
(203) 643-8022
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael
Sinclair
Sent: Tuesday, January 22, 2008 8:21 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: How do I get rid of a DBF Table??
Now that is interesting! I can run some memory checkers over night
and see if I can find a flaky memory chip on one of the machines.
Is there any way to fix the SYS_TALBLES table? The bad row appears
to be isolated to the SYS_COMMENTS table.
Mike
Emmitt Dove wrote:
Michael,
I see Mike Byerly has responded, but the question remains how the
table
got
flagged as a DBF in the first place. If you're not doing that on
purpose,
then something is causing corruption in your SYS_TABLES table.
I had a condition once where table and column names in a database were
getting changed to oddball characters. Sometimes it would be
something
like
"orders" getting changed to "orders a". This was a DOS app
running on
DOS machines back in the mid-90s.
I fought this one for months. I finally made a trip to the plant in
question to try to figure it out. After looking at several
examples of
the
corruption, it struck me that in each case the replacement
character was
32
ASCII characters higher than what it should have been. This set
off bells
in my head. 32 is one of the magic numbers in binary, represented
by the
sixth bit of a byte.
Being familiar with binary systems and the inner workings of
computers, I
finally figured out that one of the PCs had a flaky memory chip.
Here's
what would happen: When R:BASE loaded it would create a DATA
segment in
memory. Because of the way DOS worked, this would always be in the
same
physical area of RAM. R:BASE reads the database structure from
FILE 1 and
retains that in memory. But, whenever it adds or deletes a row, it
must
change the row count for the table, and that means updating the
data in
FILE
1. So it would place a lock on FILE 1, reread the data, change the
row
count for the table in question, rewrite FILE 1 (not just the piece of
data
but the entire file), then release the lock on the file.
Well, what was happening is that the PC with the flaky memory chip
had the
non-maskable interrupt turned off. The NMI was how the PC was
supposed to
recognize memory gone bad and shut down. But on this machine it was
turned
off. And, to make matters worse, the memory wasn't totally bad -
it would
just teeter between 1 and 0. Since all this machine did was run our
R:BASE
application, it never showed up anywhere else. It wouldn't always
do this
in R:BASE - just on occasions, because the flaky memory had to go
flaky
while in the middle of the update to file 1, after the read but
before the
write.
Once I was onto the nature of the problem, it became fairly simple to
locate
the machine - there were only a couple in the plant that did
nothing but
run
our application. I located it, replaced the PC, and the problem never
occurred again.
The point of this lengthy story is to point out that in a DOS
system this
kind of corruption is possible. It sounds as if something on one
of your
systems is causing a bit to flip that ends up corrupting your
SYS_TABLES
table, making the normal table look like a DBF. I'm not certain
what the
integer values are that indicate table type, and how far off a normal
table
and a DBF are, but I'd wager that it would be 1, 2, 4, 8, 16, 32,
64 or
128.
I recommend that you start doing some sleuthing to figure out which
machine
might be causing the issue.
Emmitt Dove
Manager, DairyPak Business Systems
Evergreen Packaging, Inc.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
(203) 643-8022
-----Original Message-----
From: Michael Sinclair [mailto:[EMAIL PROTECTED] Sent: Tuesday,
January 22, 2008 6:25 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: How do I get rid of a DBF Table??
For some reason my email is not making it to the list server, and
now I am stuck!
Can you post this for me?
Hi all!
Every now and then, in Rbase for DOS, I get some sort of corruption
where a table gets turned into a DBF table.
DROP tablename and DROP viewname don't fix it. I can't make a new
table with the same name. If I type
LIST table name I get the usual data regarding the columns followed
at the end by the following...
Current number of rows: DBF
How do I fix this?
How do I prevent this?
Mike
