Visual FoxPro - تم رفض الوصول إلى الملفات

https://stackoverflow.com/questions/1336564

20-09-2019
|

سؤال

نظام ERP لدينا هو مختلفي. البيانات الفعلية هي SQL، ولكن الجداول التي تحتوي على معلومات المستخدم، ملفات التعريف، الحقوق، الأمن، إلخ في Visual FoxPro.

أحتاج إلى الوصول الحصري إلى قاعدة بيانات VFP. أزل الجميع من النظام باستخدام البرنامج نفسه، ويشير إلى أن الجميع خارج النظام. أحصل على الاستجابة التالية إلى التعليمات البرمجية التالية:

set excl on
open data l:\M2MDATA\Util\util.dbc excl

الاستجابة التي أحصل عليها هي: تم رفض الوصول إلى الملفات. ذهبت إلى مدير الخادم ولا يوجد لديه أي ملفات مفتوحة في دليل VFP الخاص بنا.

هل هناك أمر في VFP سيسمح لي بتحديد من / ما الذي يفتح الملف و / أو طريقة لقتل أي جلسات داخل FoxPro التي تفعل؟

حاولت googling ذلك ولكن لم يكن لديك حظ.

المحلول

قد ترغب في التحقق من مستكشف العملية من sysinternals (Microsoft).

http://technet.microsoft.com/en-us/sysinternals/default.aspx.

يمكنك استخدام البحث عن | خيار مقبض الملفات أو DLL ووضعها واسم ملف DBC. سيقول لك عملية Explorer معرف العملية والعملية التي تحتوي على الملف مفتوحا.

إذا كنت تقاسم الملف على الشبكة (خادم الملفات أو نظير إلى نظير)، فهناك إلى "خادم" وتشغيل إدارة الكمبيوتر. انتقل إلى أسفل المجلدات المشتركة> الملفات المفتوحة ونتأمل أن نرى قائمة الملفات المفتوحة على الكمبيوتر من قبل المستخدمين الآخرين على الشبكة.

ريك

نصائح أخرى

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

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

nStatus = 0
try
   use L:\M2MData\Util\Util.dbc shared
   ** Ok so far, now try exclusive
   nStatus = 1
   use L:\M2MData\Util\Util.dbc EXCLUSIVE
   nStatus = 2

catch to loTrapMsg
   messagebox( "Can't get exclusive use of DBC" )

endtry 

if nStatus = 2
   ** you have exclusive use of it as a simple TABLE
   ** Now, what do you want to do
   use
   open database L:\M2MData\Util\Util.dbc EXCLUSIVE

endif

من الممكن أن يتعطل بعض البرنامج أثناء فتح قاعدة البيانات (ترك قفل غيبوبة) أو يتم توصيل قاعدة البيانات عبر مشاركة شبكة لا تحرير المورد.

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

إلقاء نظرة على موقع دعم Microsoft لخادم التأمين الانتهازية والإعدادات المفتوحة المخزنة مؤقتا. قد تحتاج إلى تعيين EnableOplocks إلى 0 و cachedopenlimit إلى 0 كما تصف المقالات. أيضا فحص الفيروسات عند الوصول سيئة السمعة لهذا النوع من الأشياء.

بالإضافة إلى أداة Explorer Sysinternals الممتازة المذكورة، استخدم أداة تسمى Unlocker والتي تتيح لك النقر بزر الماوس الأيمن فوق أي ملف على الخادم ومشاهدة عمليات القفل.

هناك أيضا أداة أخرى SysInternals تسمى "المقبض" الذي يعمل في المطالبة ويعطي الكثير من المعلومات حول العمليات التي تحتوي على مقابض على ملف أو ملفات معينة.

يمكنك تجربة هذا:

أعد تشغيل الخادم (إن أمكن). الآن لا أحد يستخدمه.
احصل على قائمة الجداول المرتبطة ب DBC وكتابة برنامج نصي لفتح كل جدول بشكل فردي ويكسل. هل تفشل أي من المفاتيح؟
ربما، يعود أحد الجداول مرتبطا بجدول على خادم آخر.

فقط بعض الأفكار.

قد يستحق التأكد من أنه يمكنك فتحه من أجل الوصول المشترك للتأكد من أنه ليس مشكلة أذونات.

لقد حصلت على تلك الرسالة من قبل ومشكلة بسيطة، قم بتشغيل Windows Explorer وحاول فتح المجلد حيث يوجد الملف. إذا لم تتمكن من الوصول إلى المجلد، فهل Visual FoxPro. أفترض أنك تستخدم مجلد المشاركة لأنك تذكر أنك تستخدم محرك الأقراص L. CMIIW :)

كان لدي نفس المشكلة (لا توجد وصول حصرية إلى DBC)، ولكن سبب آخر.

نحن الحصول على وصول بروتوكولينج وبعض الأنشطة في ملف نصي معالجته عبر أوامر منخفضة المستوى (FOPEN، FSEEK، FUPLS، FCLOSE، FCREATE). نحن نفعل ذلك منذ 1 أبريل 2000، دون أي مشاكل.

بعد "حدث شبكة ضارة شديدة" نظامنا لا يزال يركض، ولكن في سرعة الحلزون المفرط. استغرق كل إجراء protocolled حوالي 5 دقائق. من الواضح أن FoxPro أعاد ربط الإجراءات المنخفضة المستوى خلال 5 دقائق وتخطيها أخيرا (دون أي إشعار، راجع للشغل).

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

لا فكرة، كيف يتم توصيل هذا، ولكن بعد ذلك، كان كل شيء على ما يرام مرة أخرى ولا يزال. الخادم هو novell netware، والتي أنا لست pantiliar معها.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow