I would not run D ALL^DMSQF. I would read the documentation first and then run the appropriate DMS* option(s). Some of the concerns Jim mentioned would have been addressed if you follow the documentation.
----- Original Message ----- From: "Jim Self" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 24, 2004 11:28 PM Subject: Re: [Hardhats-members] SQLI > I have been wondering for a while now why the SQLI files in the OpenVistA distributions > are all empty. I see now that you have to run ALLF^DMSQF to process the Fileman data > definitions and generate the SQL table and column names. > > That would seem to be an answer to Bhaskar's question. A major concern of any mapping of > fileman data definitions to SQL or any other general data query engine is in the > generation of acceptable field or column names. One aim of SQLI, according to the > documentation I read, is to provide a common basis for extracting such features from the > data definitions so that mappings provided by different vendors of SQL engines can be > somewhat consistent and compatible across VistA sites. > > Is SQLI used as a starting point by any of the Fileman to SQL implementations? Is SQLI > still being developed or maintained? If so, it should greatly simplify the process of > mapping Fileman to AIDA or even to PostgreSQL or MySQL, etc. > > I will look into that one of these days, but it is not a high priority. I have always > avoided SQL as a means of accessing MUMPS data because it has always seemed intrinsically > less efficient, more complicated, and less capable than utilizing a query engine directly > implemented in MUMPS. Looking at SQLI has strengthened that impression. However, now that > we are using GT.M on Linux a number of Open Source database implementations are readily > available for experimentation and comparison. > > >On Thu, 2004-08-19 at 16:33, steven mcphelan wrote: > >> If you are running Vista on Cache, you have a SQL manager built into > >> Cache. As stated though, you need to mapped the VistA FM file > >> structure. > > > >Steve, so a separate mapping from Fileman fields to M globals is > >required no matter what M implementation is used? If so, is this > >mapping available (e.g., is it available under FOIA)? > > > >In theory, once the mapping is defined, there would be a one time effort > >to convert the mapping to each SQL engine, following which there would > >only be a need to update it whenever the mapping changes (which > >hopefully is not very common, since one would expect the VistA schema to > >be reasonably static). > > > >Thanx in advance for your insight. > > > >Regards > >-- Bhaskar > > --------------------------------------- > Jim Self > Systems Architect, Lead Developer > VMTH Computer Services, UC Davis > (http://www.vmth.ucdavis.edu/us/jaself) > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Hardhats-members mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
