ينتقل الوصول أحيانًا إلى السجل الموجود عند حفظ سجل جديد - Access2k FE/SQL2005 BE

Question

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

لدي قاعدة بيانات Access حيث قمت مؤخرًا بترحيل الجداول إلى SQL 2005، ويستمر Access في العمل للمستخدمين كواجهة أمامية توفر النماذج والتقارير والاستعلامات.

ومع ذلك، منذ الانتقال إلى إعداد Access FE/SQL BE، قام المستخدمون بالإبلاغ عن ذلك أحيانا, ، عندما يقومون بإدخال سجل جديد، فإنهم ينقرون على نموذج فرعي (لحفظ السجل) أو ينقرون على حفظ في القائمة نفسها، فينتقل إلى سجل موجود.تم حفظ السجل الجديد، ولكن لسبب ما، يتحول الوصول إلى سجل مختلف أثناء تحديثه.يجب على المستخدم بعد ذلك إغلاق السجل والعثور على السجل المحفوظ ومواصلة تحريره.

سيناريو:يقوم المستخدم بإدخال عرض أسعار ويملأ جميع تفاصيل عرض الأسعار ، العميل ، التاريخ ، وما إلى ذلك ، ثم النقر في النموذج الفرعي لعناصر السطر لإضافة منتج (أو النقر فوق حفظ في القائمة) ، وفجأة يعرض نموذج عرض الأسعار (والنموذج الفرعي لعنصر السطر) تفاصيل بعض عروض الأسعار العشوائية.يمكن أن يكون الاقتباس العشوائي حديثًا، أو منذ سنوات مضت، وليس له أي شيء مشترك مع الاقتباس الذي كانوا يدخلونه.

يحدث هذا السلوك الغريب فقط عند إدراج سجل جديد، ولا يحدث أبدًا عند تحرير سجل موجود.يخبرني المستخدمون أن هذا يحدث "في كثير من الأحيانعندما يذهبون لإضافة (عرض أسعار، عميل، أي شيء) جديد بعد فتح قاعدة البيانات.

لقد لاحظت أن هذا يحدث فقط في النماذج التي تحتوي على نماذج فرعية، لذا فإن فكرتي الأولى هي أن الأمر يتعلق بإرسال Access عبر بيانات النموذج الفرعي قبل حفظ بيانات النموذج، مما يتسبب في انتهاك PK.ولكن يبدو أن هذا لا يحدث:لا توجد أخطاء على خادم SQL، وتم حفظ السجل بنجاح.إجبار المستخدمين على حفظ سجل النموذج الرئيسي قبل إضافة سجلات النماذج الفرعية (أيفي عرض أسعار، فإن إجبارهم على حفظ عرض الأسعار قبل أن يتمكنوا من إضافة عناصر سطر) لم ينجح، بل يتسبب فقط في الانتقال (أحيانًا) عند الحفظ.

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

الخادم الذي يقوم بتشغيل الجداول هو SQL Server 2005، ويستخدم المستخدمون مزيجًا من Access 2000 و2003، ومعظمهم من XP SP3 مع اثنين من صناديق Win2k القديمة.إنهم يستخدمون النسخ المتماثل للدمج ويقوم اثنان من المستخدمين بتشغيل إصدارات SSEE2005 المنسوخة والاشتراك في الخادم الرئيسي.لا يتم نسخ معظم المستخدمين، فقط يتم الاتصال مباشرة بالخادم عبر اتصالات عميل ODBC أو SQL الأصلي.لكنني تأكدت من أن هذا يحدث لجميع المستخدمين، عادةً مرة أو مرتين يوميًا، وقد حدث لي ذلك من قبل.لذا فهي ليست مشكلة مستخدم.

أسوأ ما في هذا السلوك هو أنه يحدث في بعض الأحيان فقط ولم أتمكن من العثور على سيناريو من شأنه أن يحدث دائماً تسبب في حدوث ذلك.

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

تحديث: (1/10/09) تم حل المشكلة بفضل ديفيد فينتون.إن تعيين النموذج على وضع إدخال البيانات (Form.DataEntry = true) قبل فتحه لإضافة سجلات يؤدي بالفعل إلى منع القفز.لم يبلغ العميل عن أي مشكلات على الإطلاق منذ أن قمت بتغيير هذا قبل أسبوع.

Answer 1

يقوم العميل بالإبلاغ عن مشكلات مماثلة من حين لآخر.بدأ الأمر فورًا بعد أن بدأوا في استخدام النسخ المتماثل المدمج.

لقد أبلغت العديد من جهات الاتصال داخل مجموعة منتجات Microsoft Access بالإضافة إلى زملائي في Access وSQL Server MVPs.

يرجى إرسال عنوان بريدك الإلكتروني عبر البريد الإلكتروني حتى أتمكن من إعادة توجيهه إلى جهات الاتصال الخاصة بي في Microsoft حيث أفترض أنهم يريدون الاتصال بك مباشرةً.توني في granite.ab.ca

راجع للشغل ممتاز في استكشاف الأخطاء وإصلاحها ووصف تفصيلي للمشكلة.

Answer 2

يبدو بالتأكيد وكأنه مشكلة قفل السجل.هل تستخدم الأرقام التلقائية كـ PK؟هل حاولت جهازي كمبيوتر إضافة سجل في نفس النموذج في نفس الوقت (بمعنى أن أحدهما سيطلق حدث الإدراج بينما أضاف الآخر سجلاً جديدًا في النموذج الأول ولكنه لا يزال يقوم بتحريره)؟

هل يمكنك التحقق بطريقة أو بأخرى مما إذا كان PK للسجل المدرج بعد هل يظل الإدراج في الجدول مشابهًا لـ PK المعطى قبل الإدراج (عن طريق إضافة عدد قليل من "debug.print" إلى التعليمات البرمجية الخاصة بك على سبيل المثال)؟

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

Answer 3

أنا أتساءل عن السيناريو الذي تستخدم فيه نموذجًا لإضافة سجلات تحتوي على أي سجلات أخرى يمكن للمستخدم الانتقال إليها.

أي أنني لا أؤمن باستخدام نفس النموذج لتحرير السجلات المستخدم في إنشائها.

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

ضع في اعتبارك أنه في سيناريو النموذج الرئيسي/النموذج الفرعي، يؤدي إنشاء سجل في النموذج الفرعي عندما يكون النموذج الأصلي غير محفوظ إلى حفظ السجل الأصلي.قد ترغب في التحقق مما إذا كان هناك أي تعليمة برمجية في أحداث الإدراج والتحديث للنموذج الرئيسي قد تؤدي إلى إعادة الاستعلام عن النموذج الرئيسي عند إدراج سجل جديد (يتم تشغيله عن طريق تحرير النموذج الفرعي).

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

Answer 4

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

Answer 5

سبب هذه المشكلة هو دمج مشغل النسخ المتماثل.في هذا المشغل (هذه المشكلة تبدأ من SQL 2005 server، في SQL 2000 server هذه ليست مشاكل واضحة) يقوم النسخ المتماثل بإدراج بعض البيانات في جداول النسخ المتماثل مع الهويات والوصول إلى هذا العدد من الهوية بدلاً من إدراج مسافة مسافة النموذج الحقيقي.قرأت أن الوصول يستخدم @@IDENTITY insetad لـ SCOPE_IDENTITY وهذه مشكلة.لتجنب ذلك، يجب عليك تغيير مشغل الدمج بطريقة تقوم في مشغل الإدراج في البداية بحفظ القيمة الحالية من @@identity في المتغير وفي نهاية قيمة إدراج المشغل في الجدول المؤقت كهوية مع قيمة البداية لما هو مكتوب في المتغير.سيؤدي هذا إلى تصحيح @@iddentity وسيحصل الوصول على القيمة الصحيحة.

في بداية الزناد أعلن @identity int أعلن @strsql فارشار(128) تعيين @identity=@@IDENTITY AR نهاية شيء من هذا القبيل تعيين @strsql = 'حدد الهوية (int، '+CAST(@identity ك varchar(15)) +',1) كمعرف في #temp' تنفيذي(@strsql) et ال ويجب أن توضع بين إذا @@error <> 0 فشل الانتقال
و أعاد

سيتم حل مشكلة الوصول ليس فقط في النموذج ولكن مباشرة في جدول ارتباط ODBC أيضًا.

أنا أبحث عن طريقة كيفية إضافة هذا تلقائيًا لدمج مشغل النسخ المتماثل (إدراج بشكل أساسي).

Answer 6

هذا خطأ في اتصال Access وSQL.يأخذ الوصول هوية السجل الجديد من @@IDENTITY وعند الانتهاء من إدخال السجل، يقوم بإعادة تحميل البيانات بناءً على القيمة من @@IDENTITY القيمة من SQL.في SQL 200، يتم إدراج مشغل الدمج وAccess عادةً بشكل جيد.من مشغل الدمج SQL 2005، يحتوي مشغل الدمج على جزء ما يتم فيه إدخال البيانات في بعض جداول النسخ المتماثل للدمج والتي لها هوية وتغيير قيمة نموذج @IDDENTITY لتلك الخاصة بالسجل الذي تم إدخاله حديثًا من Access.

أحد الحلول هو تغيير كل مشغلات الإدراج لحفظ @IDDENTITY في بدايته في متغير وفي نهاية المشغل، أدخل سجل وهمي في جدول #temp كعمود هوية مع حفظ قيمة البداية للمتغير مسبقًا.

لقد وجدت هذا الحل في مكان ما على الشبكة عندما تأثرت بهذه المشكلة أيضًا قبل أسبوع.كنت أقوم بنقل قاعدة البيانات من SQL 200 إلى SQL 2008 ثم وجدت هذه المشكلة المتعلقة بالهوية في Access.أظن أن النسخ المتماثل لأنه عندما كنت أقوم بإزالة أحد الاشتراكات بدأ كل شيء في العمل بشكل جيد ولكن بعد إعادة إنشائه تم محوه مرة أخرى.

أستخدم هذا لحل المشكلة (مأخوذ من مكان ما على الشبكة).

في بداية دمج إدراج الزناد

أعلن @identity int

أعلن @strsql varchar(128)

تعيين @identity=@@IDENTITY

وفي نهاية الدمج، أدخل الزناد

قم بتعيين @strsql='selectidentity(int,'+CAST(@identity as varchar(15)) +',1) كمعرف في #temp'

تنفيذي(@strsql)

يجب وضع الكود الأخير في مكان /*إدراج النهاية في هذا المكان*/ في دمج كود النسخ المتماثل

إذا @@خطأ <> 0

انتقل إلى الفشل

/*أدخل النهاية في هذا المكان*/

يعود

لكنني أبحث عن طريقة للقيام بذلك تلقائيًا لجميع مشغلات الدمج الموجودة عند النشر وعلى جميع مشغلات الدمج الموجودة في الاشتراكات الحالية والمستقبلية.

Answer 7

0 لقد وجدت هذا

http://jagbarcelo.blogspot.com/search/label/identity

لكني لا أعرف هل يمكنني استخدامه في SQL 2008.