I don't know if I uderstood your mail completelly, but I'll try to help you.
You can create a view at the database that points to an external database. Depending on your database engine this is done by one or another way. Then you can access this view from Remedy using a view form. Regards, Jose Huerta http://theremedyforit.com/ On Thu, Jan 19, 2012 at 23:32, Susan Palmer <suzanpal...@gmail.com> wrote: > ** > Hi Everyone, > > Currently we house all data necessary for various Remedy operations in > Remedy forms. It has a 'flow-down' mentality so top feeds to next level > and that level feeds to next level etc. All other systems we have access > the necessary data from Remedy. > > Of course there is always the issue of data correctness, which really has > nothing to do with Remedy specifically. But it's been decided that some > specific data will be stored in another separate database and all systems > will access it from there (much like they do now accessing it from > Remedy). The new database will be much more accurate (tongue in cheek) and > will not have data correctness issues. > > That's the basic background. > > So I'm looking for solutions that provide me the easiest way to access > that data stored in the separate database seamlessly. I don't want to > bring it all into a Remedy form and then access it from there since > basically that takes me to where I currently am (which works just fine but > is being discouraged). For instance, all information about an > Organization is in the Organization Information form and when a 'Site' > belonging to that Organization is created much of the Org info is > automatically set into the new Site record. So instead of starting at the > Org form to create a Site I need to start at the Site form and pull in the > Org data (sql set fields). Or maybe I do a display form for the Org data > (view form with data displayed) and still create the Site from that display > record via set fields. Either way how do I get that Org info without using > a menu selection (600 choices) or needing to know exact verbiage. We need > to have the Org information stored in the Site record for easy reporting > and querying, although maybe that's just my mindset. I would think it > would be less efficient to always be calling to another database. We're > talking about approximately 30 fields from the Org record. > > I'm just having a little trouble putting my arms around this and shifting > my Remedy centric thinking. We're talking about 600 Org and 50,000 Sites > but that number will double in 1-2 years and continue at that growth. > Relatively small in comparison to many systems but needs to be scalable. > > I'd appreciate any help triggering my thought process towards the most > correct path which may be one that hasn't even crossed that mind. > > Thanks, > > Susan Palmer > ShopperTrak > 200 W Monroe St 11th Fl > Chicago, IL 60606 > 312-529-5325 > spal...@shoppertrak.com > > ARS v7.5P4 > Oracle 10.2 > We currently use v7.5P7 client tool but will be moving to web (although > many postings question that decision) > Our prod server services US, CH, UK, Middle East > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
