Ah....didn't know it was a 'process' 'cant' :)....so, in those situations I have setup external scripts that do a timed sync of data, and then use that 'local' table to do what was needed. I personally think the entire discussion is stupid, because they are trying to save bandwidth, but end up using more of it because you need to do a complete copy of the table, typically at a minimum of daily, if not more often.
The Sync was performed through various methods at various places...in SQL 2000 it was DTS jobs, but those have been replaced with a new technology that I can't pull off the top of my head....one place used Tibco to grab the data from the source and insert it at the DB level in the Remedy DB. Yet another used Pentaho suite (yes, the same one that AI is now utilizing) to get data from the source and put it where it was needed. Really how it gets there is virtually irrelevant as long as you can get it where you need...but yes, if you can't do a live link, then you can either store it locally (as discussed above), or you could integrate through Web Services, or really any other type of live integration technology. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Brittain, Mark Sent: Tuesday, February 05, 2013 10:20 AM To: [email protected] Subject: Re: Query external database LJ, Technically I know I can do it but I was told I could not use a db link. So I am stuck looking for an alternative. If none exist then maybe I can get that changed. Mark -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, February 05, 2013 12:14 PM To: [email protected] Subject: Re: Query external database Mark, I'm not sure who told you that, but I'm not familiar with any changes to the Remedy architecture that would prevent that type of thing, in fact I know I did it in 7.5...and think I did it as late as 7.6.04...but I'm not sure the info you received was correct. Now, I know that some network/server teams don't like DB Links and I've been told in a few corp environments that 'you can't do that', but not from a technical perspective, but from a bandwidth eating perspective.... -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Brittain, Mark Sent: Tuesday, February 05, 2013 10:11 AM To: [email protected] Subject: Query external database ** Hi All, Back in the day of 6.3, I could run SQL queries in active links or filters like select first_name, last_name, from employeetable@xyz where active = 'A'. There was a database link set up between the AR Server and the database. I could also set up views using the same table reference. This was really convenient and I could easy test queries with AR Utilities. After we moved to 7.6 I had planned on using a database link for similar situations but was told I could not use a database link. Are there any alternatives? Thanks Mark Mark Brittain Remedy Developer ITILv3 Foundation NaviSite - A Time Warner Cable Company [email protected] <mailto:[email protected]> Office: 315-453-2912 x5335 Mobile: 315-882.5360 ________________________________ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
