Re: Export import all after a crash
> Le 23 oct. 2017 à 14:34, Jeremy French via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Hi Arnaud, > > You can pause indexes during the SQL import with: Thanks Jeremy. I should have read more… -- Arnaud ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Export import all after a crash
Hi Arnaud, You can pause indexes during the SQL import with: Begin SQL ALTER DATABASE DISABLE INDEXES; ALTER DATABASE DISABLE CONSTRAINTS; End SQL and then after the import completes, restore indexes with: Begin SQL ALTER DATABASE ENABLE INDEXES; ALTER DATABASE ENABLE CONSTRAINTS; End SQL Details at: http://doc.4d.com/4Dv16R4/4D/16-R4/ALTER-DATABASE.300-3451136.en.html - Jeremy French > On Oct 23, 2017, at 6:45 AM, Arnaud de Montard via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > PAUSE INDEXES does not exist too, I suppose it may result in a faster import. ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Export import all after a crash
> Le 22 oct. 2017 à 23:17, Chuck Miller via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Or you could use in error call and simply skip the bad records. I would also > try opening I. C/S and use sql to fill a me empty data file you can use same > on error stuff. Finally I did like this: • repair "standart" check records in table before/after = one record lost in one table (a proof that a guardian angel for the unconscious exists) • export with SQL EXPORT DATA That's just one line of code, as Pat said. Tim, pictures and blob are exported this way. The whole result is a folder whith some sub folders and files, it's very very very fast. • import just a bit more than one line: loop through table numbers, if the export folder above references the table, import the corresponding sql instructions file with SQL EXECUTE SCRIPT. 4D writes the same SQL that 4D understands (which is not true for other DB's, BTW) •others, specific v12 Hopefully there is no object fields in that version… DISABLE TRIGGERS doesn't exist, so one may need some tool to "freeze" triggers (in case some "on insert" trigger refers to another table, due to the import order, it could cause errors). Moreover, executing triggers in such an import is out of interest. PAUSE INDEXES does not exist too, I suppose it may result in a faster import. Many thanks to all for your answers and comments! -- Arnaud de Montard ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Export import all after a crash
Or you could use in error call and simply skip the bad records. I would also try opening I. C/S and use sql to fill a me empty data file you can use same on error stuff. Regards Chuck Sent from my iPhone > On Oct 22, 2017, at 1:20 PM, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > You may have to write the export method and run it a few times and see where > it dies. Keep track of the record number or the loop counter you use when > processing the records in the table. Then you patch the export method to jump > over the records that cause export problems in each export run. Run the > export again and repeat if necessary excluding more damaged records you find. ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Export import all after a crash
On Oct 22, 2017, at 2:00 PM, Arnaud de Montard wrote: > Unbelievable but a customer of mine has always thought that any backup > solution was really too expensive. Predictable has occurred, crash, no > backup, only a damaged data. I think I'll never understand how people can > have such a disregard for their own work (10 years of input, 4 users C/S). > Hopefully the cost of repair will make him change his mind… > > The damaged data can be opened, but MSC says it must be repaired. After > repairing "standard" and verification, MSC says "it's OK" but it's not, very > strange things happen. > > The solution to get a workable 4dd is to export all/import all, I think, but > my experience of such a situation is near to zero. > > I tried SQL EXPORT SELECTON to detect what tables have unreadable records in > the damaged data, 2 tables (the biggest, of course). > > • 1st question, where do I export from? The damaged data, or the repaired by > MSC one? You can try both, but you should have better results from the repaired one. Try doing MSC standard repair more than one time. Repair and then repair the repaired data file. That will sometimes fix super damaged data files. Also, if you can’t get a good data file with the advanced “recover by tag” way in MSC you really do have big problems. That should fix even the most damaged of data files by just skipping over bad records that it encounters. > • 2nd question, how to export? A loop through table with SEND RECORD, or SQL > EXPORT SELECTION? > (given that I think I'm able to detect damaged records and ignore them in the > exported selections) I would use SEND RECORD. Particularly if there are BLOB, picture or object fields in the record. You can bang out the code in just a few hours. You know exactly how to do it. Just a few nested for loops with SEND RECORD, NEXT RECORD on the inside. You may have to write the export method and run it a few times and see where it dies. Keep track of the record number or the loop counter you use when processing the records in the table. Then you patch the export method to jump over the records that cause export problems in each export run. Run the export again and repeat if necessary excluding more damaged records you find. Good luck on recovering the data. I’ve been there myself and I know it is no fun. Just keep telling yourself “the client is paying me for every hour I’m working on this and this whole mess is all his fault anyway.” Without you efforts now he would have zero data recovered. Most people will buy a fire extinguisher after their house burns down. Hopefully, your client will be one of those type people and get on an offsite backup plan after they pay the bill to fix this mess. Tim Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Export import all after a crash
SQL EXPORT SELECTION will certainly be faster ... and simpler to write ... Pat On 22 October 2017 at 11:10, Arnaud de Montard via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Unbelievable but a customer of mine has always thought that any backup > solution was really too expensive. Predictable has occurred, crash, no > backup, only a damaged data. I think I'll never understand how people can > have such a disregard for their own work (10 years of input, 4 users C/S). > Hopefully the cost of repair will make him change his mind… > > The damaged data can be opened, but MSC says it must be repaired. After > repairing "standard" and verification, MSC says "it's OK" but it's not, > very strange things happen. > > The solution to get a workable 4dd is to export all/import all, I think, > but my experience of such a situation is near to zero. > > I tried SQL EXPORT SELECTON to detect what tables have unreadable records > in the damaged data, 2 tables (the biggest, of course). > > • 1st question, where do I export from? The damaged data, or the repaired > by MSC one? > > • 2nd question, how to export? A loop through table with SEND RECORD, or > SQL EXPORT SELECTION? > (given that I think I'm able to detect damaged records and ignore them in > the exported selections) > > TIA, > > -- > Arnaud de Montard > > > ** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** -- * CatBase - Top Dog in Data Publishing tel: +44 (0) 207 118 7889 w: http://www.catbase.com skype: pat.bensky * ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Export import all after a crash
Unbelievable but a customer of mine has always thought that any backup solution was really too expensive. Predictable has occurred, crash, no backup, only a damaged data. I think I'll never understand how people can have such a disregard for their own work (10 years of input, 4 users C/S). Hopefully the cost of repair will make him change his mind… The damaged data can be opened, but MSC says it must be repaired. After repairing "standard" and verification, MSC says "it's OK" but it's not, very strange things happen. The solution to get a workable 4dd is to export all/import all, I think, but my experience of such a situation is near to zero. I tried SQL EXPORT SELECTON to detect what tables have unreadable records in the damaged data, 2 tables (the biggest, of course). • 1st question, where do I export from? The damaged data, or the repaired by MSC one? • 2nd question, how to export? A loop through table with SEND RECORD, or SQL EXPORT SELECTION? (given that I think I'm able to detect damaged records and ignore them in the exported selections) TIA, -- Arnaud de Montard ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
