I know of some uniface users which decided to use SEQ in their production not only for data transfer between uniface applications, but for exchange infos to and from some external non-uniface processings as well. Think they would not be too happy beeing pushed to use some other filebased datastorage concept. And this is not only a matter of costs.

We use it to transfer things like the pratt table, database structure update scripts and other 'generic' data alongside our software releases. However, the issues with changing file structure, and the low speed of access are both problems we have had to build workarounds for, so I am considering moving to SQLite or similar when my base Uniface version permits. 

We use SEQ as a dummy path. Due to some bug(s) in earlier versions of Uniface, sometimes end-users were presented with a "Log On" form (where they had to click cancel and the whole application was just gone, with data lost of course). We have solved this issue by redirecting the $UUU and $IDF and $SYS paths to a SEQ:| - this solved the problem. We still have this settings in our deployment .asn files, but I suppose there should be no problem to get rid of this now (we're currently on Uniface 9.6.06 X504).

Yes we use SEQ in a "security system"-application to store ID:s while the network/database is down. In Uniface7 we used the DB3-driver and thanks to SEQ we were able to continue with the same program although DB3 was removed, and no need for any kind of local database installation on any of those local machines. It's not that difficult to rewrite it with filedump and fileload, but..... Regards Rogerw.

ulrich-merkel said I know of some uniface users which decided to use SEQ in their production not only for data transfer between uniface applications, but for exchange infos to and from some external non-uniface processings as well. Think they would not be too happy beeing pushed to use some other filebased datastorage concept. And this is not only a matter of costs.

Thanks you Uli, I have asked Andreas to follow up directly, so we have some specific details. 

What I really need is some way of storing reasonably large rowsets of data (~500 rows containing at least one SC*) in such a way as they can be shipped with a .uar and accessed from within it, allowing 'patching' of this data out, and maintenance of several different versions.    We ship .seq files containing the sql scripts necessary to update the database to a new version, and suffer from trying to implement a testing environment in that entire copies of the .seq files need to be kept, and they need to be updated manually to match the patch level being implemented. If they (or their replacement) were able to be implemented within a .uar, then they would be shipped with the patch, and the latest version for the currently implemented patch on the user site would be automatically used.... 

There are probably still a few installations out there that use SEQ to store UOBJECT (when using COUNTERS) or PRATT.PRINTER (to store user specific printer definitions). It was a popular way of doing things in Uniface 5. There are alternatives: The old Uniface Counters are neither very practical from a programming and installing /system administration point of view and are not used very often in new development. You can either used UUID's or a Sequence in your database. For user specific printer definitions Uniface now has the concept of logical printers which is a better way than storing a local PRATT.PRINTER.

 We use it internally in our development and testing environments to share some tables between applications running on different Uniface versions. Our customers also use it to mount archived data (from C-ISAM files converted to SEQ) as CIS is not available anymore. I am not sure this is still used nowadays.

AFAIK customers use it to: 1) Exchange data when an unstructured field is part of the table 2) Saving locally part of Uniface Runtime Repo, specifically PRATT table Gianni