تم تغيير سجل الوصول المرتبط "سجل DB" من قبل مستخدم آخر "

Question

أنا الحفاظ على Access Multiuser 2000 DB مرتبط بقاعدة بيانات MSSQL2000، غير مكتوبة بي.

تصميم قاعدة البيانات ضعيف جدا، لذلك عليك أن تتحمل معي.

على شكل "العميل"، هناك حقل "Customer_id" يحتاج افتراضيا إلى الحصول على معرف العميل المتاح التالي، ولكن المستخدم لديه خيار تجاوز هذا الاختيار مع معرف عميل موجود.

الآن، حقل Customer_ID ليس هو PK من جدول العميل. انها أيضا ليست فريدة من نوعها.

إذا استدعاء العميل مرتين لتقديم وظيفة، فستحصل الجدول على سجلتين، ولكل منها مع نفس معلومات العميل، ونفس معرف العميل.

إذا قام المستخدم بإنشاء تذكرة جديدة، يقوم Access بإجراء بحث سريع لمعرف العميل المتوفر التالي ويملأه. لكنه لا يوفر السجل. من الواضح أن هناك مشكلة - يتعين على اثنين من المستخدمين تتبع عمل بعضهم البعض حتى لا يقومون بتنفيذ معرف العميل.

لذلك أريد تعديل زر "السجل الجديد" حتى يحفظ التذكرة مباشرة بعد إنشاء واحدة جديدة.

المشكلة هي، عندما أقوم باختبار التغيير، أحصل على "تم تغيير هذا السجل من قبل مستخدم آخر منذ أن بدأت تحريره".

بالتأكيد لا يوجد مستخدمون آخرون على DB. كان "المستخدم الآخر" يفترض أن سيدتي القسري.

أيه أفكار؟

Answer 1

ألق نظرة على الجدول المرتبط في SQL Server 2000. هل لديك حقل يحتوي على نوع Datatype؟ سوف يوفر لك الوصول رسالة الخطأ هذه في سيناريو جدول مرتبط إذا كان لديك حقل بت التي لا تحتوي على قيمة افتراضية.

قد لا يكون الخطأ في قضيتك، لكنني عانيت من نفس قاعدة بيانات Access 2007 وتتبع المشكلة في حقل بت دون قيمة افتراضية.

Answer 2

لقد رأيت هذا السلوك من قبل وهذا إصلاحه بالنسبة لي:

حاول إضافة حقل طابع زمني إلى الجدول (ما عليك سوى إضافة هذا الحقل وتحديث جداولك المرتبطة. لا تحتاج إلى ملء هذا الحقل مع أي نوع من البيانات).

Answer 3

يحدث الخطأ الذي تحصل عليه عادة عندما:

1. أنت تقوم بتحرير سجل في شكل ونموذج قذر (أي التعديلات غير المحفوظة)،

و

2. تقوم بتشغيل التعليمات البرمجية التي تستخدم DAO أو ADO لتشغيل SQL لتحديث نفس السجل.

إلى Jet، هذا هو اثنين من المستخدمين "، لأنه عمليات تحرير مختلفة. تم تحديث الجدول الأساسي بواسطة تحديث SQL، في حين أن البيانات الموجودة في النموذج المخزن المؤقت الآن قديم.

الحل المعتاد هو فرض حفظ قبل تشغيل تحديث SQL:

  If Me.Dirty Then
     Me.Dirty = False
  End If
  [run your SQL update here]

ولكن إذا كنت تستخدم النماذج لتحرير السجل، يجب عليك القيام بجميع التحديثات في النموذج، بدلا من اللجوء إلى SQL للقيام بالتحديث.

يجب القيام بالموقف الذي تصفه بإنشاء تسلسلك الخاص بهذه الطريقة:

1. المستخدم يضرب زر تسجيل جديد.

2. احسب قيمة التسلسل التالي وتخزينها في متغير.

3. أدخل سجل جديد بقيمة التسلسل هذه عبر إدراج SQL.

4 ا. إذا كان النموذج الخاص بك ملزما لجميع السجلات في الجدول، فلاطلب نموذج تحرير البيانات (على افتراض أن زر التسجيل الجديد في النموذج الذي يقوم فيه المستخدمون بتحرير البيانات)، واستخدم إشارة مرجعية التنقل للانتقال إلى السجل الجديد بقيمة التسلسل قمت بتخزينها في المتغير في الخطوة 2.

4B. إذا كان النموذج الخاص بك ليس ملزمة لجميع السجلات (لأنه لا ينبغي أن يكون إذا كانت قاعدة بيانات مصممة بشكل جيد)، فستتغير سجلات سجلات التسجيل لتحميل السجل الجديد فقط.

بديل آخر هو تجنب إدراج ومطلب SQL (أو إعادة تعيين سجلات المسجلات) وإضافة سجل جديد في النموذج الحالي، قم بتعيين حقل التسلسل إلى القيمة الجديدة وحفظ السجل على الفور.

النقطة الأساسية هي أنه لهذا العمل في بيئة متعددة المستخدمين، يجب حفظ السجل بمجرد تعيين قيمة التسلسل إليها - لا يمكنك ترك التسجيل معلقا هناك غير محفوظة، لأن هذا يعني تتوفر قيمة التسلسل المتطابقة للمستخدمين الآخرين، والتي تطلب من كارثة أخرى.

Answer 4

هذا سؤال قديم، الذي صادفته من Google، لذلك سأقدم إجابتي.

في برنامج تشغيل ODBC، تأكد من تشغيل النسخة الصف. إذا كان الجدول بالفعل في Access، فسيتعين عليك إسقاطه وإعادة الارتباط إلى الجدول المصدر.

يجب أن تكون قادرا على معرفة ما إذا كان لديك تمكين إصدار ROW لأن الوصول، يجب أن يضيف عمود إلى طاولتك xmin.

Answer 5

أود أن أتبع ما إذا كان المستخدم قد تجاوز العميل الجديد مع قيمة خاصة بهم. إذا لم يفعلوا ذلك، فيجب أن يكون التطبيق الخاص بك قادرا على التحقق من وجود نسخة مكررة قبل التوفير والزيادة الذاتية فقط مرة أخرى، ولم يمانع المستخدم باستخدام الافتراضي. ربما حتى بعض المؤشر للمستخدم الذي كان عليك اختيار قيمة مختلفة تلقائيا.

Answer 6

كان لدي أيضا نفس المشكلة. كنت أحاول التحديث في جدول باستخدام الربيع MVC والإسبات. في حالتي، يحتوي عمود الإصدار في الجدول على قيمة أكثر من 1 (أي 3) ومع ذلك فإن معلومات التحديث في استعلام التحديث الخاص بي تحتوي على إصدار إصدار 1.

Answer 7

كانت مشكلاتنا هي أن النهاية الأمامية للوصول كانت تحاول حفظ int (نعم / لا) في حقل بت mssql (0/1). تعمل تغيير قاعدة بيانات MSSQL إلى حقول INT مثل سحر.

Answer 8

لقد أتيت للتو موقف آخر ينشئ هذا الخطأ. في جدول MySQL، كان لدي أعمدة تاريخين كانت لها قيمة افتراضية في البداية "0000-00-00". في وقت لاحق تم تغييره إلى NULL الافتراضي ولكن العديد من الصفوف أبقى القيمة "0000-00-00". اضطررت إلى إعادة تعيين القيم يدويا إلى NULL لوقف الخطأ.

استغرق الأمر الكثير من الوقت لمعرفة ما كان يجمع الخطأ، HTH شخص آخر.

Answer 9

يمكن أيضا إلقاء هذا الخطأ إذا كان جدول SQL Server يحتوي على عمود Datetime2 (في حالتي مع القيمة الافتراضية ل SysDateTime ()). تغيير Datatype مرة أخرى إلى DateTime الافتراضي Current_timestamp توقف الخطأ.