DOS application data archiving due to end of life cycle

    DOS-application (Clipper) of the organization is transferred to a modern platform. The question arose of what to do with data accumulated over more than 10 years and “chopped” over years, and the not-so-wide “database” table contains more than a million records. While the leadership was determining the decision, I asked what the theory says and whether there are regulatory documents in this regard. There were few practical recommendations.

    In the article by V.I. Tikhonov “Organization of archival storage of electronic documents: problems, practices, recommendations” classified the following approaches to archiving ED:

    Migration


    It consists in transferring archived data to a new application. The appropriateness in this case is doubtful, since for current calculations data from previous years are not required, and differences in structures entail a significant number of uncertainties, resolved mainly manually.

    Some personal migration experience recalls that this is a troublesome business. Usually the story is not dragged, but limited to account balances (Accounting), a couple of certificates from individuals (Salary). And they begin a new life from the first working day of January.

    Conversion


    - transformation of the database structure into other forms of electronic documents. Those. reports (forms) generated by the application into a systematic set of files in any generally accepted readable format (.txt, .xls, .doc, .pdf).
    With a high frequency of reporting (monthly) and a large number of reporting objects, labor costs can be great, and managing the final archive can be difficult.
    In clinical cases (the structure of the original database is not documented or unavailable), conversion with subsequent parsing of reports may be the only way to upload data (at least, their semantics are clear).
    In the Oracle database, the PL / SQL package AS_READ_XLSX is useful for analyzing the contents of xlsx reports , and the Libre Office utility is used for mass conversion of xls to xlsx:
    soffice --headless --convert-to xlsx --outdir <папка_назначения> <файл.xls>
    

    Emulation and virtualization


    Since any conversion does not exclude errors and losses, the indisputable advantage of the approach is access to the original data from the original application. Labor costs are minimal, options are possible:

    • VirtualBox virtual machine with FREE DOS. I remembered memory management, and, after several attempts, started the application.
    • DOSemu on a Linux server. The application started without any additional manipulations. Client access via SSH (from Windows using PutTTY, which does not require installation). On the client, copy-paste of screen reports and forms into new documents is possible.
      On the server, you can fill the zipped Clipper bases into an iso image and, upon starting the application, unzip it to a temporary folder, keeping the original unchanged.
    • Dosbox JS-DOS API: we launch DOS in the browser / Geek magazine (did not try).
    • Windows virtualization.

    Encapsulation


    - Export (upload) the database to the structured files of cross-platform formats (XML).
    You can contextually search XML documents and view them with any browser. The volumes of the final XML archive can grow significantly relative to DBF.
    Export / import of tables in XML is supported by most DBMSs, and tools of built-in languages ​​(DOM, XMLQuery, XSLT) allow you to handle more complex structures.
    Exporting DBF to XML “as is” is an intermediate solution. It is preferable to 'cut off the excess' and transform the relational model into a hierarchical (natural for XML). By separating the data from the presentation, you can style the XML files or feed the XML to the report generators.

    I return to the task. It was supposed to import into the database the main DBMS of the organization - Oracle (migration again!). But importing and merging bases is half the battle. And then what? Provide a set of reports that duplicate the functions of both the original and the new application?
    With both hands for emulation, but prepared for any development. Experienced colleagues suggested: in Oracle import from Access works well with attached DBFs. There is one thing: DBF tables contain fields with integers packed in C4. And with different encodings ... Well, you yourself understand. In this case, the PL / SQL table import package from the BLOB was stored .

    So far, the story has no continuation.

    Updated 06.15.16

    Also popular now: