Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars

From: Paul Thomas (paul_at_tmsl.demon.co.uk)
Date: 01/31/04

  • Next message: Markku Kolkka: "Re: KDE 3.1.95 rpm install" 
    To: fedora-list@redhat.com
Date: Sat, 31 Jan 2004 22:40:10 +0000

    On 31/01/2004 19:08 Richard Welty wrote:
    > [snip]
    > > but consider this: what if a company wants to migrate their desktops to
    > > Linux but can't get the required connectivity to MS-SQL? Should they
    > > meekly accept that they're locked into M$ for ever? Or should they
    > > investigate ways of replacing MS-SQL (maybe even with another
    > proprietry,
    > > but multi-platform, DB)? Which would you advise?
    >
    > they need to look at the entirety of their application and consider what
    > it
    > is that they are doing that is causing the lock in, and then start taking
    > an iterative approach to breaking the lock.

    It's nice to see that surrender is not an option for either :)

    > there's no one true path, it depends on the situation. usually they've
    > coded a lot in C# or VB making it hard to migrate (but if they've done
    > that, they're SOL when it comes to non-MS desktops anyway.)

    VB would be the main culprit around here. Google throws up a few porting
    possibilities.

    > if it's non-standard SQL in an otherwise portable langauge, then
    > they probably need to look at whether they have properly
    > implemented an M-V-C architecture that hides the SQL from the
    > bulk of the app, so that the SQL is isolated and can be dealt
    > with w/o massive disruption. at that point, you look at what
    > non-standard features are in use, and figure out how to revise
    > the architecture to facilitate migration.
    >
    > the main thing is that you may need to move the database first,
    > before you can move the desktop. this all presumes that there
    > is no answer involving JDBC or ODBC, which make desktop
    > migration fairly straightforward and independent of database
    > migration.

    Agreed. My instinct is to migrate server/db first. It gives the users a
    nice warm feeling when their server isn't regularly BSOD-ing or having to
    be re-booted each time a piece of software is installed.

    > you can do a forklift, and switch everything all at once, but it
    > won't be seamless, it never is. people who want to do forklift
    > conversions need to understand the implications, but often
    > they're neck deep before they finally understand.

    At which point the PHB comes in and announces "tea break over. Back on
    your heads". You know, we're going to have to find something to disagree
    over else this thread could get boring very quickly ;) 

    -- 
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller 
Business |
| Computer Consultants         | 
http://www.thomas-micro-systems-ltd.co.uk   |
+------------------------------+---------------------------------------------+
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Markku Kolkka: "Re: KDE 3.1.95 rpm install"