#DELETED

के रूप में दिखाए जाने वाली पंक्तियों में मेरे पास एक्सेस का उपयोग करते समय एक कंप्यूटर पर #DELETED के रूप में दिखाए गए तालिका में डेटा की पंक्तियां हैं लेकिन वे SQL डेटाबेस और एक्सेस का उपयोग कर अन्य कंप्यूटरों में ठीक हैं। ऐसा लगता है कि यह केवल 200 पंक्तियां हैं। एक्सेस 2007 संस्करण और ओडीबीसी एमएसजेट ड्राइवर एक ही & प्रत्येक कंप्यूटर पर नवीनतम दिखते हैं। एक सुझाव था कि किसी भी पीके या एफके को int में बदलना है, लेकिन वे पहले से ही हैं।#DELETED

इसके लिए कोई फिक्स के लिए कोई विचार?

स्रोत

2012-03-12 Matt Rowles

यह तब होता है जब तालिका प्राथमिक कुंजी मान, एमएस एक्सेस का समर्थन करने वाली सीमा से अधिक है, आमतौर पर यदि आप SQL सर्वर में "BigInt" प्रकार का उपयोग कर रहे हैं, तो यदि आप केवल डेटा को पढ़ना चाहते हैं तो बस "स्नैप बनाएं -शॉट "तालिका के लिए क्वेरी और सभी पंक्तियां सही तरीके से प्रदर्शित होंगी क्योंकि" स्नैप-शॉट "को सभी इंडेक्स को पढ़ने की आवश्यकता नहीं है।

यदि आपको किसी भी समय इन पंक्तियों में डेटा अपडेट करने की आवश्यकता है तो मैं इसके बजाय एक एडीओ रिकॉर्डसेट का उपयोग करने का सुझाव देता हूं।

स्रोत

2012-03-16 10:49:50

यदि यह एक एक्सेस समस्या है, तो यह केवल एक उपयोगकर्ता को कैसे प्रभावित करेगा और सभी एक बार में नहीं? – TesseractE

कॉल करने में कठिनाई, सेटअप में शायद छोटे अंतर हो सकते हैं, शायद सर्विस पैक या पैच स्तर, 32-बिट बनाम 64, दोनों उदाहरणों को अलग-अलग रहस्यों को देखे बिना मुझे डर लगता है। –

कारण मैं पूछता हूं कि मैंने इस परियोजना को एक प्रोजेक्ट पर देखा है, लेकिन यह कभी-कभी कई उपयोगकर्ताओं को कभी प्रभावित नहीं करता है, और आमतौर पर अपने आप से दूर चला जाता है। जाहिर है, मैं इसे पूरी तरह से टालना पसंद करूंगा, लेकिन अगर यह 'बड़ा' मुद्दा था जो व्यापक रूप से कारण के रूप में रिपोर्ट किया गया है, तो यह थोड़ा और व्यापक होना चाहिए, मुझे सोचना चाहिए। – TesseractE

एसक्यूएल में प्राथमिक कुंजी डेटा प्रकार के लिए की सांख्यिक (18,0) बजाय bigint उपयोग पर विचार करें। एमएस एक्सेस प्रभावी रूप से बड़े पूर्णांक पीके को हल कर सकता है यदि यह SQL सर्वर पक्ष पर संख्यात्मक डेटा प्रकार के रूप में सेट किया गया है। मैं एक्सेस 2010 के साथ SQL 2008R2 पर एक ही समस्या में भाग गया जहां एक बड़ी पीके का उपयोग करते समय सभी पंक्तियों ने '#DELETED' प्रदर्शित किया।

स्रोत

2013-01-03 17:21:00 eeasterly

जानकारी के लिए धन्यवाद, मैं जल्द ही इसे बाहर आज़माउंगा। लेकिन क्या आपने यह देखा है: http://stackoverflow.com/questions/6838374/sql-server-bigint-or-decimal18-0-for-primary-key? निश्चित नहीं है कि दशमलव बनाम संख्यात्मक को एक बड़ा अंतर माना जाता है। –

ठीक है बस मेरे लिए काम करने वाले समाधान को जोड़ना चाहते हैं।

मैंने एमएस एक्सेस में कुछ दृश्यों को जोड़ा और वे ठीक काम कर रहे थे। कुछ समय बाद मैंने कॉलम में से एक का प्रकार बदल दिया जो पहले इंटीजर था और मैंने इसे VARCHAR बनाया। चूंकि यह कॉलम मेरी तालिका की प्राथमिक कुंजी थी (जिसे मैंने एमएस एक्सेस में दृश्य जोड़ने के दौरान प्राथमिक कुंजी के रूप में भी चुना था), उस परिवर्तन के बाद "#DELETED" दिखाना शुरू हो गया। इस समस्या को हल करने के लिए मैंने "ALTER VIEW" कथन के साथ एक ही दृश्य को फिर से निष्पादित किया और sp_refreshview 'VIEW_NAME' का उपयोग किया।

ऐसा करने के बाद यह मेरे लिए काम करना शुरू कर दिया। उम्मीद है कि यह किसी को भी एक ही समस्या का सामना करने में मदद करता है।

स्रोत

2015-12-10 08:38:58

यह थोड़ा जटिल था, लेकिन धन्यवाद। –

मैं बिना किसी मुद्दे के वर्षों तक एक्सेस फ्रंट सिरों को SQL Server 2000, 2008 R2 पर कनेक्ट कर रहा हूं। हार्ड डिस्क विफलता के बाद, मैंने विंडोज 7 (64-बिट) कंप्यूटर पर SQL Server 2014 डेवलपर को पुनर्स्थापित किया और अचानक मेरे एक्सेस 2010 फॉर्म को नए रिकॉर्ड में जाने या रिबन पर सहेजें पर क्लिक करते समय डरावना # हर फ़ील्ड में हटा दिया गया।

यह अजीब था क्योंकि किसी अन्य कंप्यूटर पर एक समान विंडोज 7 (64-बिट) स्थापना में कोई समस्या नहीं थी। खैर, लगभग समान है। नई हार्ड डिस्क पर SQL Server 2014 स्थापित करने के बाद, मुझे केवल मूल क्लाइंट 11.0 ड्राइवर स्थापित किया गया था, और इसलिए मैंने अपने एक्सेस वीबीए कोड में DRIVER = SQL सर्वर मूल क्लाइंट 11.0 का उपयोग करने के लिए ओडीबीसी कनेक्शन स्ट्रिंग को संशोधित किया। एक्सेस फॉर्म का उपयोग करते समय मैंने तुरंत डाले गए रिकॉर्ड के प्रत्येक फ़ील्ड में # हटा दिया।

जांच ने 'अच्छे' कंप्यूटर के बीच अंतर दिखाया जो सम्मिलित रिकॉर्ड्स को सही तरीके से संभाला गया था, और 'खराब' कंप्यूटर जो # हटाया गया था मूल क्लाइंट 10.0 ड्राइवर की उपस्थिति/अनुपस्थिति थी। मैंने माइक्रोसॉफ्ट से 10.0 ड्राइवर डाउनलोड किया, इसे स्थापित किया और डीडीआरईआर = एसक्यूएल सर्वर मूल क्लाइंट 10.0 का उपयोग किए गए सभी ओडीबीसी कनेक्शन स्ट्रिंग्स को बीमा करने के लिए अपना कोड चेक किया।

सबकुछ अब ठीक से काम करता है # हटाए गए समस्याओं के साथ।

स्रोत

2016-04-27 14:10:58 Charax

मेरे पास एक ही #DELETED समस्या थी, और ऐसा इसलिए था क्योंकि प्राथमिक कुंजी डेटा प्रकार bigint था। चूंकि मैं किसी तृतीय-पक्ष एप्लिकेशन द्वारा बनाई गई तालिका से पूछताछ कर रहा था, इसलिए मैं डेटा प्रकार को संशोधित करने में सक्षम नहीं था, इसलिए मैंने तालिका पर एक दृश्य बनाया और डेटा प्रकार को int में परिवर्तित करने के लिए CAST का उपयोग किया (यह जांचने के बाद कि मूल्य तालिका में एक अतिप्रवाह नहीं होगा)।

स्रोत

2016-12-12 13:56:20 davebrads

यदि आप उस फ़ील्ड पर प्राथमिक कुंजी सेट करते हैं जहां SQL ROW_NUMBER() फ़ंक्शन का उपयोग कर रहा है तो आप इसे int में डाल सकते हैं। डिफ़ॉल्ट रूप से ROW_NUMBER() int64 (bigInt) है।

स्रोत

2017-09-14 17:39:00

यह अजीब व्यवहार एक एसक्यूएल 2017 डेटाबेस (पहले एसक्यूएल 2008R2 डेटाबेस की ओर इशारा किया गया) तक पहुंचने का संकेत दे सकता है। जब हमने एक अद्यतन ओडीबीसी चालक (एसक्यूएल मूल क्लाइंट 11) के साथ एक नया डीएसएन बनाया, तो व्यवहार सामान्य हो गया।

स्रोत

2018-03-01 19:02:35

उत्तर

संबंधित मुद्दे