ماذا يحدث عندما لا يستطيع iDBQuery الإجابة عن سؤال؟

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

مثال تطبيقي: تسأل «ما معدّل تسرّب عملائنا؟» لكن لا توجد بيانات اشتراك أو إلغاء متّصلة. يوضّح iDBQuery أنه لا يستطيع حساب التسرّب دون ذلك المصدر ويقترح توصيله، بدلًا من إعادة رقم مُختلَق.

وما يميّزه هو الصدق بالتصميم. فلأن كل إجابة حقيقية مُسنَدة إلى صفوف مصدرية ومعروضة مع استعلام SQL الخاص بها، ليس لدى iDBQuery أي سبيل لتمرير تخمين غير مُسنَد على أنه نتيجة؛ فإن لم يستطع تتبّع رقم إلى بياناتك، لن يقدّمه على أنه حقيقة. وهذا نقيض روبوت الدردشة العام، الذي ينتج بسعادة رقمًا واثقًا لكنه بلا أساس. وبالنسبة إلى الأسئلة الصعبة فعلًا لكن القابلة للإجابة، سيحاول وكيل المحلّل إجراء تحقيق متعدد الخطوات قبل أن يخلص إلى نتيجة، وإن ظلّ عاجزًا عن الوصول، يبلّغ بما جرّبه وما ينقص. فـ«لا» الصادرة عن iDBQuery جديرة بالثقة، وتأتي عادةً مصحوبةً بالخطوة التالية للوصول إلى «نعم».