The Work of the Ancients

  • I started in my current job 6 months ago. I work for a large state department. They have a lot of old MS Access databases and applications. (Over 100 at least.) At first, because I only saw a couple of them, I thought it was some bad programmers writing terrible code. However I've learned that the majority of them were written by someone at least 15 years ago, in remote offices all over the state. It was probably something like someone needing to get something done, they had Office installed on their system. Either they fired up Access and started playing around with it, or they son/daughter took a class on it in school and wrote something, which has been running ever since. None of these systems are good, but I've gained respect for the original developer whoever they were, because they were able to cobble together something back in the day, to get an immediate need met. And those things have been working ever since.

    Rod

  • I musta been blindsiding meself over how long I been doing this for. I remember fighting the Dirty Reads that were still being done by The Big Three SQL DB's, dang - has to be around SQL 7, like 1997, I converted a large thick Windows Dataflex app from flat file Btrieve to SQL, and chose MS's flavour. (happy I did I guess). and it's still running today, sure many iterations of updates and all the drama, but it still has the orig data from 1986 when I first wrote it, and it was first lit up.

    Steve Jones, leave my foggy memory alone, some ghosts (and skeletons) still stalk there!

  • I remember going to to the London British Museum last year and looking at an exhibit of record keeping from one of the ancient civilizations. They were financial records written on clay with reed pens used to mark indentations. There was a translation of the information into English.

    The information looked normalised ( at least to 1NF ) with all fields complete and accurate with no replication of fields.

    A couple of things made me smile...

    The records were better than I have seen in some 20th century organisations.

    Those record keepers would have been seriously well educated for their time and hats off to them their backup procedure got them 2,500 years to the digital age.

    Whoever was in charge of those guys made sure that they were well supported chose the best people and must have been very careful about record storage.

    Its not always about the technology its the way you implement it.;-)

  • Separate "data sets" from the current database and some things live on for years

    An application I helped with in 1999 loaded Corporate ledger data from 1989 through 1999 for a web based retrieval application function. Large amounts of ledger detail was stored in a SQL Server data warehouse. The data definition was flexible enough to support transition to a new ledger sources and integration of other ledger sources as the corporate world evolved. The size is just short of 2 TB.

    The data structure and extract methodologies were well thought out, creating a single view of multiple ledgers with low level detail. This is unheard of in the world of ledger detail. As the company evolved/merged/reorganized more ledger data was summarized the history, and each new system lost it's historic detail. in 2011 the ledger feed was terminated with the thought the application would go away.

    Years later this Ledger data warehouse is the sole historic repository of leger data still used in contract closeout and recon, Rate determination, and audit projects. The original Application containing the feature is long gone, but the Actuals data warehouse remains a standalone application no one can afford to delete, despite corporate pressure to eliminate old applications.

    Lesson learned, transaction databases can age away, but their history may live on.

  • One database that I'm working with has been in continuous use since SQL Server 7 in 1999. The major app on top of it has been totally rewritten 5 times, each time with different UI technologies. We're now entering discussions regarding rewrite iteration #6, leaning towards using MVC and jQuery for the UI.

    The major app has also acquired several "bolt-on" satellite apps over the years that use a subset of the main database and major app's functionality, along with their own SQL Server databases.

    It just keeps on going and growing...

  • We have a major system still running MS Access/Foxpro '97. From the data I would say it's been in use since '97 was new.

    Or only SQL Server installations in production at this time (3 servers, multiple databases) are all SQL Server 2005, with data predating that migrated from the still-running Foxpro application.

    Sad?

    You bet.

    The development staff simply can't get commitment from Management to get a move-on in upgrading these systems Before they all fail.

    And the real tragedy? Our primary "product" is Data...

  • There is some basic code I wrote in the early 80's that is still being used. In recent times we rewrote some sql code in 2012 that had been in use since 2000.

  • bazmunro (10/3/2015)


    ...I converted a large thick Windows Dataflex app from flat file Btrieve to SQL, and chose MS's flavour...

    Oh, man, I feel your pain! I spent nine years in a DataFlex environment in the '90s and was SO HAPPY when better tools came out! Apparently they made a ridiculously cheap offer, like $50-100, for a complete development set at a police convention of some sort and a huge number of installs appeared on the networks. It was all over the place and really hard to maintain and fix when the non-IT officers got in over their heads.

    Looks like it's more of a front-end tool now that can use pretty much any DB as a data store. They have a free 3-user license available for developers, I suppose if I ever have a stroke I might be interested in downloading it and checking it out.

    I was so glad to be rid of it. I can't remember if the name DataFlex appears on my resume.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • We imported the data (going back to 1992) from our old HP3000 into a SQL database shortly before our HP3000 died a couple of years ago. At this point it's for reference to old data only, but it's there.

    Our "new" SQL database for our "new" ERP system is 9 years old.

    We are using Access databases that were first created in Paradox (not sure when), and were converted to Access in 2002. They are currently being moved to SQL, though the Access front-ends will remain in place.

    You couldn't possibly call us early adopters of anything.

  • The firm I'm contracting for now was my employer back in 1985. The team I was on built a mainframe DB in a DBMS called Model 204 (wicked fast, bitmapped indexes way back then). That data and the structure we put together is still being used, though now it's on SQL Server. In the financial services industry, old market data never dies...


    And then again, I might be wrong ...
    David Webb

  • I started work at a previous employer where the COBOL/ISAM system ran using DG COBOL and INFOS ISAM files for the data. It was already 12 years old when I started working for them. I worked there eleven years. It is now ten years later and that application is still running. While there we "integrated" it with SQL Server (downloads only) to provide enhanced reporting capabilities. That led the SQL Database to integrate with web based applications to create electronic delivery and print on demand capabilities. Then came a web based store that was built against Oracle but get its data from the SQL Server database. Another application was written that interfaced with both the SQL Server database and an Oracle database to allow for updates to the ISAM data tables used by the COBOL application.

    Confused yet?

    Just say, that COBOL application has its tentacles everywhere and will be difficult to replace, and several have tried and failed.

  • Our main production system was put into use april 1999. At startup data from two other systems it replaced was loaded into the database (mainly client information and stuff like that). I don't know the exact years of the replacement systems, but both of them were in use in the early 90's sometime.

  • An app and database I designed and built back in 1999 (go live date) is still going today. It was SQL 7, Now it is running on sql 2012.

    I was an employee of the company way back then. The app has had a small amount of development over the years , perhaps 30-40 hours a year. It has survived 3 take overs (I only survived 2!!) and I still do development on it as a contractor (self employed for last 7 years) . The only changes are generally enhancements or where Accounting standards have changed so we need to alter a calculation. Easy stuff unfortunately, can never really charge enough to live on that one. But based on its reliable performance I get lots of other great development jobs.

  • David.Poole (10/2/2015)


    I know the UK tax system was supposed to be migrated to a client server architecture when such things were fashionable. As far as I am aware it is still on a mainframe that predates Microsoft.

    Although ICL's New Range mainframe architecture was conceived in the late 60s and saw first customer releases in the early 1970s the actual hardware that the Inland Revenue system runs on has changed quite often - still based on the same architecture, of course, but no more the same hardware than an Intel core i7 is the same hardware as an Intel 80386.

    I think the current "hardware" is from Fujitsu (it was running ICL hardware until Fujitsu took ICL over - but most ICL mainframe hardware was by then either powered either by processors designed and manufactured by Fujitsu to ICL specifications, or was collections of standard Intel CPUs emulating the ICL New Range architecture). Whatever the hardware is now , it runs the ICL VME/B operating system and uses ICL's IDMSX for its database. I'm not sure whether the hardware includes a modern version of ICL's CAFS (content addressable file store) which which did the filtering component of scans in the disc drives instead of in the CPUs, if I remeber correctly that was included in the original system but it may have been dropped as processor power imporoved over the years.

    The database was originally supposed to throw away data more than 6 years old (couldn't throw away anything less than 6 years old and conform to UK tax law), but last time I knew for sure what was happening it had been running for 20 years or more and hadn't yet thrown away any data, and there was no plan to throw any away in what was then the forseeable future. It's now 40 years or more old and still going strong, so it's quite an old database, and I believe they still have all the data back to day 1 so it's not a small database.

    A few of my ex-ICL colleagues have drifted back into Fujitsu (which has been recruiting ex-ICL people, as the ones they had acquired originally get old and retire) and a few more have been there since the takeover. They are doing quite well out of supporting and enhancing stuff that was originally done a long time ago.

    Tom

  • I am currently working on an Oracle database that I believe was migrated from a hierarchical database circa '94. No later but possibly earlier.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 15 posts - 31 through 45 (of 61 total)

You must be logged in to reply to this topic. Login to reply