You previously mentioned "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."
Prior to running the generate option which runs ALL^DMSQF you can enter such Key words that the generate option will look for. Also, the option allows for more flexibility than just run the routine from a programmer's prompt. Look at the option: NAME: DMSQ PROJECT MENU TEXT: Regenerate SQLI Projection If all you do is just run the routine from the programmer's prompt, you have bypassed the varied setup steps that one may or may not want to do. But if you set up everything first before running the regenerate option, then you are more likely to get results that are more agreeable to you. ----- Original Message ----- From: "Jim Self" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, August 26, 2004 1:13 AM Subject: Re: [Hardhats-members] SQLI > Steven, > Why not D ALL^DMSQF? According to the documentation I read, it has no effect on anything > outside of one global designated for SQLI. What would you do instead? > > What documentation are you referring to Steven? I read what SQLI documentation I could > find (sqli_sm.doc and sqli_vendor.doc) before writing my previous message. That was how I > discovered ALL^DMSQF. > > Which concerns and how addressed? > > steven mcphelan wrote: > >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) > > --------------------------------------- > 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
