In planning for upgrading a client fo v16 I noted that the datafile needed to be compacted so included a compact in my upgrade plan.
A few days before I was to do the upgrade my client replace the server’s hard drive with an SSD. Ok, so when it came time to do the compact I noted that it no longer told be that the datafile needed to be compacted. I ignored that and proceeded to compact the datafile. As luck would have it the compact failed due to orphaned blobs in one of the tables. In my research of how to fix this problem I ran across this statement in a tech note on the subject from 2011 (http://kb.4d.com/assetid=76195)… Note: Solid State Disk (SSD) drives do not face this challenge, so there is actually no need to compact the data file on an SSD. In fact we recommend NOT compacting the data file on an SSD because it contributes to drive wear. For more information see Technical Note 10-09, SSDs and 4D v11 SQL. Interesting! So I won’t try the compact again, but should I be worried about the orphaned blobs? I think not, the database is working fine. Fixing the orphans per the tech note involves compacting the address table for the table in question. If I don’t need to do that I don’t particularly want to go down that road. Thanks, John John Baughman 1331 Auwaiku Street Kailua, Hawaii 96734 (808) 262-0328 john...@hawaii.rr.com > On Jul 29, 2018, at 10:12 AM, Robert McKeever via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > Either they have changed the way QUERY works, or you are missing …&;… after > the first semi-colon on lines 2, 3, and 4 of the QUERY. So, it looks like you > are really simply searching for just the last line. Probably would be quicker. > >> On Jul 29, 2018, at 4:47 AM, Two Way Communications via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> I am a bit confused… isn’t ORDA supposed to be faster than traditional >> queries? >> >> I did a test with a table containing 120,000 records. The query is on 4 >> indexed fields and returns 54,000 records. >> >> Doing the query with ORDA takes 175 milliseconds. >> Doing the query with QUERY takes 4 milliseconds. >> >> Why?? >> >> ORDA: >> $oQRYoption:=New object("queryPlan";False;"queryPath";False) >> >> $oTLD:=ds.T_Loggers_data.query("TLR.FK_REAP =:1 AND TLD_timestamp >=:2 AND >> TLD_timestamp <=:3 AND Excluded >> =:4";[REAP_sections]FK_REAP;$TSsectionStart;$TSsectionEnd;False;$oQRYoption) >> >> >> >> Traditional: >> QUERY([T_Loggers_data];[T_loggers_readings]FK_REAP=[REAP_sections]FK_REAP;*) >> >> QUERY([T_Loggers_data];[T_Loggers_data]TLD_timestamp>=$TSsectionStart;*) >> QUERY([T_Loggers_data];[T_Loggers_data]TLD_timestamp<=$TSsectionEnd;*) >> QUERY([T_Loggers_data];[T_loggers_readings]Excluded=False) >> >> >> Rudy Mortier >> Two Way Communications bvba >> >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> Archive: http://lists.4d.com/archives.html >> Options: https://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >> ********************************************************************** > > _________________________________________ > Bob McKeever http://www.mswl.com <http://www.mswl.com/> > McKeever's Software Wizardry > Port Coquitlam, B.C. > bobmckee...@mac.com > > > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
