David, For you Cache maybe the best approach for you. Cache does have a lot of flexibility in ways you can get the data. At our Hospital we have chosen Cache. We could spend a lot of time discussing the merits of each M, but the fact is some people want the features that are in Cache and others do not want to pay for them.
What I have been hoping for is a standard approach for the GUI. We have been using CSP pages but printing from the Web has been a problem for some very complicated reports. There is a plug-in for PDF that may solve that problem. If most users of Cache use CSP pages then maybe we could make that the "standard" for GUI in Cache. We would be open to other ideas. Another thing that would greatly speed up development would be being able to write through the Vista Objects using Fileman. Bob says he has an idea of how it can be done and he is willing to help. I have not had the time to work on this yet. So if you use Cache and you are doing GUI development what are you using? Are you working on the writing through Vista Objects? Another approach that may give a common GUI interface between M platforms is ESI Objects. I looked at ESI Objects a couple of years ago. It seemed to me that there was a steeper learning curve for us. You would lose (not use) some of Cache's capabilities and I think Bob was saying performance. We can not change right now but if others are developing in say VB then we could switch. Ed Walton -----Original Message----- From: David Sommers [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 22, 2004 12:22 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] modern day programming (was: Intersystems) I'd honestly say that the approach to querying data out of M and using it with someone's "bag of tricks" is the #1 way to gain adoption. Taking a page out of Microsoft's hand book - if you can get developers to use your wares (regardless of whether it's the best available) - you'll gain momentum. We have about 6 or so developers here and none of them (besides me) can use M, FM, or anything in VistA. Not saying they couldn't learn, but these are developers doing Java and Oracle for 5+ years - it's easier to hand them a SQL statement and an IDE (.NET, VB6, C, InterDev, Dreamweaver, etc) to code Web or thick apps (like CPRS). They can apply traditional OOP, libraries/frameworks, unit testing, etc. I don't think I can explain encapsulation, inheritance, unit testing, or libraries easily ... (if you know what I mean). But that's different to everyone on this list. I'm sure Jim and Greg have routines for hashing strings, one-way encryption, easy file system access, etc. I don't know these and instead use .NET for its framework to provide these. So for instance, if you want to hash the string plaintext into MD5: HashAlgorithm cs = CryptoConfig.CreateFromName("MD5"); byte[] cb = cs.ComputeHash(ASCIIEncoding.ASCII.GetBytes(plainText)); Want that in Base64? string s64 = Convert.ToBase64String(cb); I have similar functions for VB6 but I had to write the libraries that make it work. So it really is your "skillset" and your "bag of tricks" but the more flexible you are to allow external tools to work, the more likely a system will be adopted. Then there are web services... but that's another thread... :) /David. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Wednesday, December 22, 2004 12:52 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] modern day programming (was: Intersystems) I'm sure that's a big part of it. Though every product out there seems to have its own flavor of SQL, using a relational database does offer a common model, and I suppose knowledge of MySQL (say), is more "transferable" to Oracle than it is to Fileman -- though, in fact, I think Fileman is much more relational than people often realize. It is often argued that relational database technology has a stronger theoretical background than Fileman, but I'm not impressed by this argument. I may be true that relational technology is an improvement over network and hierarchical databases here, but that's not Fileman. It is often argued that support for ad hoc queries is a significant advantage of an RDBMS over Fileman, but consider what you can do with "Search" option and relational navigation. I would also point out that indexes are very much a fact of life using relational products: if a file design favors certain potential queries over others, so does RDBMS design. Perhaps the most cogent argument I've heard is that Fileman is built around pointers, which are not part of the relational model. Maybe so, but one-to-one relationships are hardly unique to Fileman, and foreign keys referencing candidate keys other than the primary key are the exception rather than the rule (and it is not clear to me whether this is really even all that useful). Beyond that, even in an RDBMS you will generally end up indexing fields you frequently use as the basis of joins. The real difference here is that multiple-valued pointers ultimately make use of a subfile, but that subfile is in an optional one-to-one relationship with the referenced file, so you may as well think of it as a nullable foreign key. When you get right down to it, even this seems to reduce to terminology (and a little bookkeeping), after all. --- "Nancy E. Anthracite" <[EMAIL PROTECTED]> wrote: > 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? > ===== A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli ==== Greg Woodhouse [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- 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 Hardhats-members@lists.sourceforge.net 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 Hardhats-members@lists.sourceforge.net 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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
