मेरे पास एक SQL Server 2008 डेटाबेस तालिका है जो प्राथमिक कुंजी के रूप में अद्वितीय पहचानकर्ता का उपयोग करती है। आवेषण पर, नई तरफ() फ़ंक्शन का उपयोग कर डेटाबेस पक्ष पर कुंजी उत्पन्न होती है।इकाई फ्रेमवर्क - GUID के साथ SaveChanges EntityKey
यह ADO.NET के साथ ठीक काम करता है। लेकिन जब मैंने एक इकाई फ्रेमवर्क 4 मॉडल में एक इकाई के रूप में इस तालिका को स्थापित किया, तो एक समस्या है। मैं इकाई को ठीक से पूछताछ करने में सक्षम हूं, लेकिन जब कोई नई इकाई बना रही है और संदर्भ पर SaveChanges() का आह्वान करते हैं, तो डेटाबेस पर जेनरेट किया गया अद्वितीय पहचानकर्ता शून्य है।
मुझे समझ में आता है कि ईएफ v1 के साथ कोई समस्या थी जहां यह परिदृश्य काम नहीं करता था, जिसे SaveChanges को कॉल करने से पहले क्लाइंट पर GUID बनाने की आवश्यकता होती थी। हालांकि, मैंने कई स्थानों पर पढ़ा था कि वे इसे ईएफ 4 में ठीक करने की योजना बना रहे थे।
मेरा प्रश्न - क्या यह परिदृश्य (अद्वितीय पहचानकर्ता की डीबी-साइड पीढ़ी) अभी भी ईएफ 4 में समर्थित नहीं है? क्या हम अभी भी ग्राहक पर GUID उत्पन्न करने के साथ अटक गए हैं?
, तुम क्यों लगता है कि आप ग्राहक पर GUID पैदा करने के साथ "अटक जाने" कर रहे हैं? यह अद्वितीय पहचानकर्ता, आईएमओ का प्राथमिक * लाभ * है। यदि आप सर्वर पर आईडी जेनरेट करना चाहते हैं, तो केवल ऑटो-वृद्धि कुंजी का उपयोग क्यों न करें? – MusiGenesis
रास्ते से बढ़िया उपनाम। :) – MusiGenesis
@MusiGenesis, 1. MissingLinq एक ऑटो जेनरेट की गई कुंजी चाहता है, सिर्फ एक int नहीं (शायद उनके पास अधिक सीमित श्रेणियां हैं)। 2. डेटाबेस उत्पन्न कुंजी का बिंदु टकराव को खत्म करना है, एक GUID के साथ 1/2^128 हो सकता है, लेकिन डेटाबेस को ऐसा क्यों न करने दें और क्लाइंट कोड को संस्थाओं को बनाने के बारे में चिंता न करें और इसके बारे में नहीं डेटाबेस कुंजी –