Chuck, > On Jul 26, 2018, at 11:50 AM, Charles Miller via 4D_Tech > <[email protected]> wrote: > > I did not. I meanty sql calls, but you are correct, object fields need to > be handled in a different way. That is why I never use object fields. I do > not think 4D should ever create field types that work in 4D but not in SQL > or vice versa. I will not use them no matter how cool they may be. There > are also SQL data types that 4D does not know about. In case of table with > object data type, I would export that table in 4D format in then import.
Yes, I agree. Type consistency across features and APIs continues to be a problem. ORDA in version 17 can't do anything with BLOB fields. > > Whether you use import or sql calls to get at data, you can use database > setting to turn off indexing while saving the data. I would do this and > then turn on indexing between each table Dealing with exporting/importing, manipulating indexes, and so on is a lot more work than what I outlined using compact. The key question is if the compacted database is viable after force quitting it during the compacting indexing process. I convinced myself it is by writing a method that exports the primary key and md5 hash of every record in the database. I compared this export before and after the compact and did not find any differences. John DeSoi, Ph.D. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
