Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!sunybcs!canisius!pavlov
From: pavlov@canisius.UUCP (Greg Pavlov)
Newsgroups: comp.databases
Subject: Re: issues/effort to convert databases
Message-ID: <2760@canisius.UUCP>
Date: 19 Jul 90 16:35:06 GMT
References: <1990Jul6.191941.185@zorch.SF-Bay.ORG> <310002@wdl1.wdl.fac.com>
Organization: Canisius College, Buffalo N.Y. 14208
Lines: 30

In article <310002@wdl1.wdl.fac.com>,eric@wdl1.wdl.fac.com (Eric Kuhnen) writes:

      [ Re Porting Databases ]:
> 
> 1)  Stay within the same query language when moving between DBMS's.
> 
      While this does often help, it is not as big a factor as it may seem.
      One reason: if you use HLIs, the mechanism and/or syntax utilized by
      vendors vary substantially (example: imbedded SQL statements vs sub-
      routine calls).  We have done cross-query language conversions that
      were relatively "easy" because the HLI interface was reasonably close.
     
> 2)  Use delimited ASCII files for data, employing an obscure delimiter.
>     For example, tab stops would not be good for conversion to Ingres
>     since Ingres doesn't like tabs.
> 
      1. I don't know what "INGRES doesn't like tabs" means.  Tabs are as 
         good as any other delimiter I can think of for INGRES.  INGRES's 
         database unload/reload utilities use them for field delimiters.

      2. I also don't think that, in most cases, delimited data is any easier
         than fixed format records.  The ideal for us has been to write a
         "dictionary converter" that reads a dictionary produced by the
         source system and generates definition, creation, and load scripts/  
         commands/whatever for the target system.  The ability to do that
         effects "ease of conversion" much more than the structure of the 
         data.  Especially in large conversions (in terms of numbers of tables).


      greg pavlov, fstrf, amherst, ny