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
