We had a similar situation to Gavin’s setup – a client with an Omnis application that had nearly 30Gb of data in a number of Omnis datafiles. We wrote a parser to convert DML commands into SQL equivalents, and a migration routine to transfer the data from Omnis datafiles to Postgres. It wasn’t an automatic process, but we were able to do the migration of data over a weekend, and swap all the libraries of the multi-library system over to SQL with our automatic updates mechanism, with very little disruption to the company. That was almost three years ago.
If you have to go to a multi-datafile setup, you should consider moving to an SQL backend.
> DF1 or SQL:
> I do not recommend using the Omnis datafiles as a long term solution for large datasets. My team has been hired to migrate the application I describe above to SQL and it?s a significant task. We?ve developed a way to do so that keeps the old code base rather than having to rewrite it all in SQL today. We cleanse various aspects of the application, then pass it through a converter that replaces all the old Omnis DML commands with ?equivalent? SQL operations. This might be an approach you want to consider once you?ve got past the immediate space issue.
> Good luck!
>> On 1 Mar 2018, at 20:25, Jeanne Reyes <firstname.lastname@example.org <mailto:email@example.com>> wrote:
>> I have a native studio database with 15 fully expanded segments totalizing
>> (3.75 gb). My understanding is that Studio can handle up to 1 terabyte of
>> data, but with only one database is not possible. I think I remember that
>> there is a way to link databases together.
I bought my friend an elephant for his room. He said “Thanks” I said “Don’t mention it”
Paul W. Mulroney We Don’t Do Simple Pty Ltd
firstname.lastname@example.org Trading as Logical Developments
www.logicaldevelopments.com.au ACN 161 009 374
Ph: +61 8 9458 3889 86 Coolgardie Street
BENTLEY WA 6102