واجهت مؤخرًا مشكلة عندما كنت أقوم ببناء نظام لإدارة العملاء لعملائي:
عند استخدام سلسلة الاتصال التالية ، يكون الموقف التالي كما يلي
connstr = "dbq ="+server.mappath ("db/#kehumsg.mdb")+"؛ defaultDir = ؛ driver = {microsoft accessDriver (*. mdb)} ؛"
setConn = server.createObject ("adodb.connection")
Conn.Openconnstr
هناك استعلام Join ،
استخدم معرف الجدول الثاني ليتم استدعاؤه ،
عادة ، يمكن ضبط RS ("B.ID") بهذه الطريقة ولكن يتم عرضه في المجموعة المقابلة للاسم المطلوب أو الرقم الترتيبي ، ولا توجد عناصر.
لا يمكنني العثور على الإجابة بعد النشر على CSDN.
أخيرًا ، استخدمت RS ("ID") لحل المشكلة. اعتقدت أن هذه المكالمة يجب أن تكون لضبط معرف الجدول الأول.
لكنه يعدل الجدول الثاني ، لكن ما أريده هو الثاني.
بعد دراستها ، اتضح أن هذا صحيح. يقوم بضبط معرف الجدول الأخير. إنه شعور جيد. يمكنني أن أجد شيئًا بنفسي ، هاها ~~
ولكن عندما كان العميل على وشك الخروج من العمل ، قال إن هناك مشكلة ولم يستطع الدخول.
الخطأ في conn.openconnstr من الاتصال أعلاه ،
لماذا يوجد خطأ هنا؟ نظرت إلى الإنترنت وقلت أن هذا هو الحال ، لذلك قمت بتغييره إلى
dbpath = server.mappath ("db/#kehumsg.mdb")
connstr = "provider = microsoft.jet.oledb.4.0 ؛ datasource =" & dbpath
setConn = server.createObject ("adodb.connection")
Conn.Openconnstr
لم أفكر كثيرًا ، ربما كان بإمكاني تجربته.
لكن الأوقات الجيدة لم تستمر طويلاً ، واليوم ذكر العميل المشكلة مرة أخرى.
عندما حصلت عليه ، كنت مقتنعا وكان استعلام مشترك وكان هناك خطأ.
لماذا هذا يحدث؟ لقد درستها مع المدير ووجدت المشكلة أخيرًا:
في هذا الوقت ، يمكن تسمية المعرف في الجدول الثاني RS ("B.ID") ويجب أن يطلق عليه بهذه الطريقة.
لا يمكن أن تفعل ذلك مثل شخصية الانضمام الأولى ،
أعتقد أنه يجب أن يكون مشكلة في محرك قاعدة البيانات. لا أعرف ما يفكر فيه الجميع
هنا نوصي بالاتصال الثاني ،
) ///////////////////////////////////////////////////////////////////////////////2
تم العثور على مشكلة أخرى ، الحل: مستخدمي إذن Windows/Temp بالإضافة إلى العنصر لتعديل الأذونات.