SKIF-BP

تحقق من إصدار ملحق CryptoPro. يمكن فحص إصدار الملحق في المتصفح هنا: https://www.cryptopro.ru/sites/default/files/products/cades/demopage/simple.html. إذا كنت تخطط للعمل مع التواقيع في IE أو FireFox، جرّب تحديث الملحق إلى الإصدار 2؛ وعند استخدام Chrome فإن الإصدار 1.5 هو الحد الأقصى حالياً.

جوهر مشكلة التدوير هو كما يلي:

كان SKIF 3 يخزّن البيانات عمودياً، أي أن رقم العمود كان سمة من سمات الترويسة أو رمز الصف:

حيث A وB سمتان للترويسة، وRow رمز الصف، وColumn هو العمود، وX هو المجموع. بعبارة أخرى، كانت كل خلية تُخزَّن في صف منفصل من جدول قاعدة البيانات.

أما في SKIF-BP فالتخزين أفقي، أي أن صف النموذج الواحد يقابل صفاً واحداً في قاعدة البيانات.

يمكن إعادة عرض البيانات عمودياً بعدة طرق، أبسطها معامل الاتحاد (union).

لدى التحليلات لدينا طريقتان لاستخدام معامل الاتحاد:

1. مكعب «Union of tables» المخصص.

2. مكعب «SQL script» العالمي.

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

لتصحيح هذا الوضع يجب عليك:

لا تزال مسألة عوامل التصفية على الفترات الزمنية مع إمكانية الحصول على فترات غير متتالية موضع نقاش حاد بين المطوّرين.

هناك حلان متاحان حالياً:

1. استخدام مكعب «SQL script» إضافي لإزالة الزائد.

2. إنشاء مصدرَين لنفس النموذج ولكن بعاملَي تصفية مختلفين.

يمكن تثبيت SKIF-BP على SQL 2005 وما أحدث. أما SKIF 3 فيمكن تثبيته على الإصدار 2000 وما أحدث. ومع ذلك نوصي بشدة بتثبيت أحدث إصدار من SQL متاح لنظام التشغيل لديك وقت نشر حزمة البرامج.

يمكن تثبيت SKIF-BP على PostgreSQL 14.3 وما أحدث.

المتطلبات النظامية الموصى بها:

المعالج: 8 أنوية، بتردد 2.90 جيجاهرتز أو أعلى.

المنصة: 32-بت أو 64-بت.

ذاكرة الوصول العشوائي: 32 جيجابايت أو أكثر.

القرص الصلب: يعتمد الحجم على حجم قاعدة البيانات، ولكن لا يقل عن 1 جيجابايت من مساحة القرص الحرة