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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> > > > >
