Hi Ben I am sorry that I was not very clear. When I tried to unload one table it works OK with writechk on.
I got a good unload file of the full db, then did my testing. The problem seems to be that no rows are unloaded for some of the tables. I have deleted all forms and reports and still get the same problem. I an going to try to drop tables, rules, PK's and FK's and see what happens. thanks for the help marc --- Ben Petersen <[EMAIL PROTECTED]> wrote: > So you were able to create a new DB from your > unloaded data, with just one > table, where you can replicate the problem? Wow. I > thought for sure you had > some corruption that wasn't being picked up > otherwise, but that wouldn't be > the case now. Can you try and run your test on > another computer? Is the > table small enough to see if the missing rows have > something in common? If > there is a unique column you can load before and > after versions of the table > (new 2nd table name) and do a select to view this > missing rows from the > second table. > > Ben Petersen > > > > On 11 Aug 2003, at 12:13, marc schluter wrote: > > > Hi Ben > > > > There are about 12 tables that loose all rows. I > > picked one table and unload all for that tab and > it > > worked OK. > > > > I did get a good unload file, reloaded the db to > make > > sure it was clean. Then, unload with writechk on > and > > bye bye rows of data. The out put file is 10% of > the > > good unload file. > > > > I must have a strange db. > > > > thanks > > marc > > > > > > --- Ben Petersen <[EMAIL PROTECTED]> wrote: > > > Mark, > > > > > > If error messages are on you could edit the > output > > > file with RCode and > > > search for "Error" to see if there is anything > > > obvious. > > > > > > Another thought would be to unload the structure > > > separately for the problem > > > table and edit it so that it creates a new DB > when > > > run. Then unload just the > > > data from the problem table (with writechk off) > and > > > load it into the new DB. > > > Once that is done, try unloading from the new DB > > > with writechk on and see > > > what happens. If that succeeds, try unloading > the > > > entire original database > > > with writechk off, rename the old database, and > run > > > the output file. Now try > > > unloading the problem table with writechk on and > see > > > what happens. > > > > > > Ben Petersen > > > > > > > > > > > > > > > On 11 Aug 2003, at 6:52, marc schluter wrote: > > > > > > > I have tested the following several times this > > > weekend > > > > and I keep loosing rows of data with writechk > on. > > > > > > > > set writechk off > > > > out 1.dat > > > > unload all > > > > out screen > > > > > > > > set writechk on > > > > out 2.dat > > > > unload all > > > > out screen > > > > > > > > set writechk off > > > > out 3.dat > > > > unload all > > > > out screen > > > > > > > > File 1.dat and 3.dat are the same size, file > 2.dat > > > is > > > > 10 times smaller. > > > > > > > > What should I look for and why would writechk > make > > > a > > > > difference in the output file? > > > > > > > > thanks > > > > marc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- "A. Razzak Memon" <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > At 07:10 AM 8/8/2003 -0700, Marc Schluter > > > wrote: > > > > > > > > > > > > >well folks > > > > > > > > > > > > > >I think I found my problem. > > > > > > > > > > > > > >If I start RBW then do Unload all, > everything > > > is > > > > > > OK. > > > > > > >Then I run > > > > > > > SET ZERO ON > > > > > > > SET WRITECHK ON > > > > > > > SET CLEAR ON > > > > > > >and the output file is smaller and I > loose > > > the > > > > > > rows. > > > > > > >Then I set writechk off and did another > > > unload > > > > > all > > > > > > and > > > > > > >it worked fine. > > > > > > > > > > > > > >It seems that writechk on will not allow > all > > > of > > > > > the > > > > > > >rows to be written to the output file and > it > > > > > > appears > > > > > > >to be the tables with dates. > > > > > > > > > > > > > >Am I crazy or is this possible? > > > > > > > > > > > > > > > > > > Marc, > > > > > > > > > > > > SET WRITECHK ON specifies R:BASE to verify > > > "EVERY" > > > > > > write to disk. > > > > > > > > > > > > So, you may need to check integrity of > your > > > > > database > > > > > > using R:SCOPE. > > > > > > > > > > > > Just for fun: > > > > > > > > > > > > Try the same scenario using the CONCOMP > > > database > > > > > > bundled with the latest R:BASE 6.5++ for > > > Windows, > > > > > > i.e., C:\RBTI\RBWIN65\SAMPLES\CONCOMP and > see > > > what > > > > > > happens. > > > > > > > > > > > > Have Fun! > > > > > > > > > > > > Very Best R:egards, > > > > > > > > > > > > Razzak. > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! SiteBuilder - Free, easy-to-use web > site > > > > > design software > > > > > http://sitebuilder.yahoo.com > > > > > > > > > > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Yahoo! SiteBuilder - Free, easy-to-use web > site > > > design software > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
