Correct me if I am wrong, but isn't the reason for so much interest in SQL that so many people in the work force are trained to make queries using SQL? Isn't the issue writing an interface that allows SQL queries of a Mumps database. Isn't that what that company in Massachusetts ( http://mde.srs-inc.com/aboutmde.html) and Cache does that people want?
On Tuesday 21 December 2004 10:51 pm, David Sommers wrote: > <quote> > We (UC Davis VMTH) have been generating comparable web pages and queries > in VMACS for 10 years now using MUMPS, HTML, and JavaScript and > comparable ADHOC queries for more than 10 years before that using > Fileman and our own query and search tools written in MUMPS. We have > avoided use of SQL because it seemed less efficient and more complicated > for our needs than using MUMPS - and much more expensive. > </quote> > > Expensive how? In terms of memory/cpu cycles and execution time or just > $$$ with license costs? > I haven't tried it personally but if an engine (such as Cache) can have > direct access to the underlying data via a language, it would seem to me > that a language written out in TSQL or M would act similarly if those > layers were given the same amount of care. If a language had to compute > something, such as SUM, then there might be execution path scenarios and > process/threading consideration but just straight record selection > shouldn't be on a factor of 2x, 3x, 4x - is it? > > To me, using a SQL connection to M and writing a JSP or ASP[.NET] page > in terms of productivity would seem to justify that route. Not to start > a flame war, I'm sure a lot of you can code M to output table TRs and > TDs tightly but I'm used to HTML/IDEs built for Web use - and they do > have their benefits. (I don't think everyone would argue that the > homebrew and GNU pages lack a little designer spunk. Instead they look > like they were coded in emacs/vi and went straight to publishing.) > > I've said this before on this thread and I'll admit it again - I do use > VB6, sometimes it's just quicker to write something without worrying > about all the little details. > > Dan Appleman, popular VB author, wrote in the book 'Moving to VB.NET'. > > I think Visual Basic programmers have been intimidated by the > C++ > crowds, who have the tendency to raise their noses and say, > "Visual > Basic is not a real object-oriented language. A real > object-oriented > language has true inheritance" - at which point, the poor VB > programmer would slink into his cubicle and churn out in an hour > as much code as the C++ programmer could generate in a week. > > You can code any project 50 ways; it's not only finding the best > approach available today but also the best one that fits your skill set. > I could code an ISAPI filter in straight C and hard-code the output of > my "HTML" page but by no means is that considered productivity (unless > I'm trying to win some benchmarks). > > Again, I haven't tried SQL to Web output so everyone else may have > horror stories but [to me] it seems to be a faster route. Question > isn't why should I use straight M but why not use SQL connections? > > /David. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jim > Self > Sent: Tuesday, December 21, 2004 7:44 PM > To: [email protected] > Subject: RE: [Hardhats-members] modern day programming (was: > Intersystems) > > Ostrander, Terry L. wrote: > >Proof is in the pudding. > > I totally agree. Concrete examples and comparisons can be quite > illuminating. > > >I created the necessary Cache' objects to > >emulate a VistA system and now I am able to perform ADHOC queries and > >write programs using modern day programming languages. For example I > >recently wrote a Mental Health Performance Monitor Web page using a > >mixture of html, JavaScript, SQL and CSP (Cache' Server Page). > > We (UC Davis VMTH) have been generating comparable web pages and queries > in VMACS for 10 > years now using MUMPS, HTML, and JavaScript and comparable ADHOC queries > for more than 10 > years before that using Fileman and our own query and search tools > written in MUMPS. We > have avoided use of SQL because it seemed less efficient and more > complicated for our > needs than using MUMPS - and much more expensive. > > >One of the SQL queries was the following > > > >select VISIT->HOSPITAL_LOCATION->NAME, > > PATIENT_NAME->NAME->NAME, > > RIGHT(PATIENT_NAME->NAME->SOCIAL_SECURITY_NUMBER,4), > > POV->CODE_NUMBER, VISIT->VISITADMIT_DATETIME, > > '' RX_DATE, > > 'NO' MEDS, > > PATIENT_NAME->NAME > > from TR557.V_POV > > where (VISIT->VISITADMIT_DATETIME >= '06/01/2003' and > > VISIT->VISITADMIT_DATETIME < '07/01/2003') > > AND (VISIT->SERVICE_CATEGORY IN ('AMBULATORY', > > 'HOSPITALIZATION')) > > > AND (POV->CODE_NUMBER IN('296.21', '296.22', > > 296.23','296.24','296.25', > > '296.26','296.30','298.0', > > '300.4','309.1','311.')) > > > >Once executed the results were presented in a online MS-Excel worksheet > >in the customers' web browser. > > > >Question how much MUMPS code would have to be written to generate this > >result set and how much additional overhead to get the result set into > > a > > >MS Excel worksheet in the customers' web browser? > > Good questions. :) > > If you were using M2Web, the answer to the second question would be zero > or none. It would > require only a change of the file extension in the query URL from .html > to .xls. If your > web browser associates .xls files with Excel, then it will be > automatically loaded into Excel. > > I don't recognize TR557.POV. I may need some assistance in relating your > example query to > familiar files and fields. Is this a reflection of data in a standard > VistA database? It > looks like a query that could be done via Fileman search. If so, what > files and fields? > > If the data you refer to is in a VistA demonstration database that I can > load on to one of > my servers then I can connect it to M2web and give you (all) a precise > answer and a > demonstration. This sort of adhoc query generally requires very little, > if any, MUMPS code > to be written. > > If I interpret your example correctly, the SQL code above is only a > small part of what you > had to write for this query to produce results in a web page. Could you > describe that for > those of us who are not familiar with CSP? > > In examples I have seen from PHP and other database-to-web scripting > interfaces, you > generally have to embed variables from your SQL results into a repeating > block of HTML or > XML or Javascript. You could do that with the M2Web, but most queries > simply require > appropriate settings of input parameters > (dbfile,format,index,find,filter,limit) to > generate the whole output. > > >Those that have animosity against Intersystems are fearful of having to > >learn something new and exciting to me. > > I think you misinterpret the motives and positions of people on this > list who advocate > other alternatives. I for one have been trying to share my enthusiasm > about connecting > MUMPS applications and data to the web (hence M2Web, MUMPS-to-Web) with > the MUMPS > community for over 10 years now. Those of us who have recently begun > learning about Linux, > BSD, Apache, Perl, PhP, Python, Mozilla, DOM, CSS, XUL, RDF, etc, etc, > etc. can not be > rightly accused of being afraid to learn. We have discovered an > incredible treasure of new > and exciting possibilities - and a new paradigm for software development > and distribution > that appears to solve many long-term and large-scale problems. > > >Terry > >SFC, USA, Retired, BACS, MCP > > --------------------------------------- > Jim Self > Systems Architect, Lead Developer > VMTH Computer Services, UC Davis > (http://www.vmth.ucdavis.edu/us/jaself) > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Nancy Anthracite ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
