I wouldn't think changing tns names would do that either.. Joe
________________________________ From: "Shellman, David" <[email protected]> To: [email protected] Sent: Wednesday, March 25, 2009 11:24:22 AM Subject: Re: View Forms ** It seems that the DBA's took some steps to limit prod instances only talking to other prod instances and dev instances only talking to dev instances. This was done through tnsnames to resolve connect strings. In this case it shouldn't have been effected because it was prod to prod connection. However it does seem that there was an effect. I now need to check the other View forms that connect to other external prod instances to see if they were effected. Dave ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe DeSouza Sent: Wednesday, March 25, 2009 11:17 AM To: [email protected] Subject: Re: View Forms ** In her case I think her view form had lost its reference to the original field probably becuase of some structural alteration of the table - and my thought would be that the table or view was modified by adding or deleting a column from the original table. That may have caused the view form to loose its reference and hence it was pointing the primary key to some other field that had nulls in it.. Joe ________________________________ From: "Gutierrez, Alejandro (HITS)" <[email protected]> To: [email protected] Sent: Wednesday, March 25, 2009 10:53:07 AM Subject: Re: View Forms ** Hi Lisa, Have you checked the underlying DB Tables for any changes? This happened to me in the past and the reason was that someone changed the length of the fields on the DB tables. Alex. ________________________________ From:Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kemes, Lisa Sent: Wednesday, March 25, 2009 8:49 AM To: [email protected] Subject: View Forms We are suddenly getting the error when we do a query on our view form: ARERR [482] This View Form contains Request IDs that are null. Ensure that the key field is set to a non-null, unique column to avoid data corruption We checked the table and there are no fields that are null and the field has no dupes (therefore is unique). Anything else we might need to check? This was working just fine a couple of days ago and has been working flawlessly for years. ARS 7.0 P5 Windows Server 2003 Oracle 10i Lisa Kemes AR System Developer Tyco Electronics 717-810-2408 tel 717-810-2124 fax [email protected] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
