मुझे SSRS में एक बहुत ही अजीब विसंगति विरासत में मिली है। 2019 का उपयोग करके एक नया SSRS इंस्टेंस बनाया गया था और ऐसा प्रतीत होता है कि यह पिछले 2016 इंस्टेंस के समान रिपोर्टसेवर डीबी का उपयोग कर रहा है। ऐसा हज़ारों रिपोर्ट और संबंधित आइटम को पोर्ट करने से बचने के लिए किया गया हो सकता है।

  • 2016 का उदाहरण अभी भी चल रहा है, हालांकि, रिपोर्टिंग सेवा डीबी तक पहुंचने के लिए उपयोग किया जाने वाला खाता अब मान्य नहीं है, इस प्रकार 2016 यूआरएल अंत का उपयोग करके रिपोर्ट तक पहुंचने का कोई भी प्रयास 'रिपोर्ट सर्वर डेटाबेस तक नहीं पहुंच सकता है।'

  • जब मैं 2019 में किसी रिपोर्ट को एक्सेस करता हूं तो मैं उसे रिपोर्ट मैनेजर में प्रस्तुत कर सकता हूं।

  • जब मैं उसी रिपोर्ट का आह्वान करता हूं, 2019 इंस्टेंस के url का उपयोग करते हुए, ReportService2010.Render() को wcf सर्विस कॉल के माध्यम से, मुझे वही त्रुटि मिलती है जैसे कि मैं 2016 इंस्टेंस के लिए सेवाओं तक पहुंच रहा था।

  • हां, मुझे पता है कि 2016 का संस्करण 2019 को किए गए कॉल को रेंडर करने का प्रयास कर रहा है क्योंकि रेंडर प्रयास और "रिपोर्ट सर्वर डेटाबेस से कनेक्ट नहीं हो सकता" त्रुटि के बारे में लॉग जानकारी केवल 2016 के त्रुटि लॉग में दिखाई देती है।

  • मैंने आईआईएस लॉग को फिर से चेक किया है और देखा है कि डब्ल्यूसीएफ सेवा 200 परिणाम के साथ रेंडर का अनुरोध करने के लिए 2019 सर्वर को कॉल कर रही है (यह आग है और भूल जाओ कि 200 हमेशा वापस आ जाता है यदि एंडपॉइंट पहुंच योग्य है)।

ऐसा लगता है कि डब्ल्यूसीएफ वास्तव में 201 9 के उदाहरण को बुला रहा है और एक रिपोर्ट का अनुरोध कर रहा है, हालांकि, उस अनुरोध के लिए लॉगिंग एसएसआरएस के 2016 के उदाहरण पर किया जा रहा है।

क्या यह रिपोर्ट सेवर डेटाबेस में कुछ अच्छी तरह से कॉन्फ़िगर नहीं किया जा सकता है?

answer

यह उपयोगकर्ता त्रुटि थी। WCF सेवा के लिए app.config सही उदाहरण की ओर इशारा कर रहा था, इसलिए सही लॉगिंग संदेश। API प्रोजेक्ट में web.config, जो सभी WCF सेवाओं को संदर्भित करता है, में एक ही कुंजी के साथ दो ऐप सेटिंग्स थीं। एक कुंजी गलत थी और उसका उपयोग ReportExecution समापन बिंदु बाइंडिंग के लिए किया गया था।

मैंने मान लिया कि विन्यास प्राचीन थे।