Ajanın bağlandığı veritabanları conf dosyasında değil, ajanın kalıcı MASTER'ında (${APPDIR}/ivd$master.sqlite) kayıtlıdır. Bir veritabanı, çalışan hizmete msql ile verilen CREATE DATABASE ya da OPEN DATABASE deyimiyle kaydedilir; CRUD, WhatsAppWebhook uygulamalarının database anahtarı, rapor uçları, MCP kipi ve ZMGOREV zamanlayıcı bu kayıt adına başvurur. Değişiklik hizmet yeniden başlatıldığında etkinleşir.

open database NETSIM storage engine firebird
  parameters 'Database Name=devdata.fdb; charSet=UTF8; User Name=SYSDBA; Password=masterkey';
comment on database NETSIM is 'Netsim Veritabanı';
alter database NETSIM set task scheduler on;
commit;

msql -U SYSDBA -W <parola> -f kayit.sql

Kayıtlar MASTER'dan sorgulanır; görev zamanlayıcı bayrağı kayıt satırının TASK SCHEDULER niteliğidir, veritabanının kendi kartında (sys.ivd$database.ivd$task_scheduler) da durur:

select o.ivd$object_name, o.ivd$description, a.ivd$attribute_name, a.ivd$value
  from master.sys.ivd$objects o
  left join master.sys.ivd$object_attributes a on a.ivd$object_id = o.ivd$object_id
 where o.ivd$type = 'DATABASE' and o.ivd$object_id > 0
 order by o.ivd$object_id, a.ivd$order;

Nitelik adları STORAGE ENGINE, ENGINE PARAMETERS ve TASK SCHEDULER'dır. Yönetim arayüzü aynı listeyi GET /AdminREST/MANAGEDDATABASES ile okur (parola maskelenir).

4.4.1 Yeni sunucuya ürün veritabanı kurmak (Veritabanı kurulumu sayfası)

Yeni kurulmuş bir PostgreSQL ya da Firebird sunucusuna ürün veritabanı, dağıtım setindeki hazır veritabanından kurulur. Yönetim arayüzünün Veritabanı → Veritabanı kurulumu sayfası (arkasında AdminREST EXECCOMMAND DBSETUP) adımları ajanın kendisinde yapar. Denetle hiçbir şey yazmaz, her adımı YAPILACAK ya da hata olarak listeler; Kur adımları uygular ve işaretliyse veritabanını OPEN DATABASE ile bu ajana kaydeder (deyim onaydan önce, parola maskeli gösterilir). Kaynak dosya ve kütüphane dosyası sunucudan seçilir ya da istemciden yüklenir.

Kütüphane kurulumu ve .fdb dosyasının yazılması ajanın hizmet hesabının o dizinlere yazma hakkı olmasını ister; hak yoksa adım bunu söyler ve dosya elle kopyalanır. İstek bitene kadar sürer (1532 paketinde PostgreSQL geri yüklemesi yaklaşık 20 saniye).

4.4.2 Kayıttaki parola mühürlüdür (ivd$master.key)

ENGINE PARAMETERS'ın Password= değeri MASTER'da düz metin durmaz: kayda yazılırken AES-256-GCM ile mühürlenir ve satırda Password=enc:<hex> görünür — yukarıdaki sorguyu çalıştıran SYSDBA bile parolayı okuyamaz. Ajan parolayı yalnız depoya bağlanırken çözer. Anahtar, ivd$master.sqlite'ın yanındaki ivd$master.key dosyasıdır (32 bayt; ilk açılışta üretilir, Linux'ta 0600). Daha önce düz metin yazılmış kayıtlar ajanın ilk açılışında kendiliğinden mühürlenir (günlükte carried a plain-text storage password; sealed). Servis kullanıcısıyla kayıtlı satırlarda parola satırda hiç durmaz; depo sunucusunun credential'ındadır (aşağıda).

4.4.3 Parola yerine işletim sistemi oturumu (OS Authentication)

Bağlantı dizesine OS Authentication=Yes yazılırsa ajan kullanıcı adı ve parola göndermez; kimlik doğrulama hizmetin altında koştuğu Windows/POSIX oturumunun kimliği üzerinden yürür. Dizede bir Password dursa bile yok sayılır, yani kayıttan parolayı tamamen çıkarabilirsiniz:

open database NETSIM storage engine firebird
  parameters 'OS Authentication=Yes; Database Name=devdata.fdb; charSet=UTF8';

4.4.4 Kayıttaki kimlik motorun servis kullanıcısıdır (engineUser)

Kayıt formunda (ya da CREATE/OPEN DATABASE … PARAMETERS'ta) verdiğiniz SYSDBA/postgres parolası kaydedilmez: ajan onunla bir kez bağlanır, depoda engineUser ayarındaki kullanıcıyı (öndeğer IVD$ENGINE) süper kullanıcı olarak kurar (PostgreSQL SUPERUSER; Firebird GRANT ADMIN ROLE + CREATE DATABASE hakkı + veritabanında DEFAULT RDB$ADMIN) ve rastgele bir parola üretir. Kullanıcı adı ile parola, depo sunucusu başına MASTER'da bir credential'da saklanır: SYS.IVD$ENGINE_<AİLE>_<SUNUCU>_<PORT> (TYPE DBLINK; ör. SYS.IVD$ENGINE_POSTGRESQL_LOCALHOST_5432). Kayıt satırı yalnız ona başvurur (Credential=SYS.…), kullanıcı adı ve parola satırda durmaz. Aynı depo sunucusunun bütün kayıtları aynı credential'ı kullanır; sunucunun son kaydı kapatılsa da credential kalır ve sonraki kayıt parolayı ondan alır. Sunucu, sunucu adı ve porttan tanınır (Firebird'de Database Name içindeki sunucu:yol ya da sunucu/port:yol öneki de sunucu adıdır, öneksiz yol yerel sunucudur; ODBC kaydı PostgreSQL sayılır). Boş sunucu adı, localhost, 127.0.0.1 ve ::1 aynı yerel sunucudur; yerel Firebird sunucusu porttan bağımsız tek credential kullanır (SYS.IVD$ENGINE_FIREBIRD_LOCALHOST), makinede tek Firebird sunucusu olduğu varsayılır. Kayıt sqlite ya da OS Authentication=Yes ise bir şey yapılmaz. Servis kullanıcısı depoda zaten varsa ve bu ajanda o sunucunun credential'ı yoksa (başka bir ajan kurmuştur) kullanıcıya dokunulmaz: kayıt verilen kimlikle yapılır ve bir uyarı gösterilir; kaydı servis kullanıcısına geçirmek için Servis kullanıcısına geçir kullanılır. Firebird'de yönetici yetkisi (RDB$ADMIN) her veritabanı dosyasına ayrı yazılır: Servis kullanıcısına geçir aynı sunucudaki bütün Firebird kayıtlarının dosyalarında bu yetkiyi verir. Dosya dışarıda (örneğin ürünün derleme aracıyla SYSDBA olarak) yeniden üretilirse yetki kaybolur ve kayıt "servis kullanıcısı bu veritabanında yetkisiz" iletisiyle açılmaz; aynı işlem yetkiyi yeniden verir. Parametreleri düzenle'de maskesiz bir parola yazılırsa o kayıt credential'dan çıkar ve kendi (mühürlü) parolasını taşır. Credential'ın parolası katalogda kodlu durur; MASTER dosyasını okuyabilen onu çözebilir — dosya izinlerini yukarıdaki gibi kısın.

4.4.5 Yükseltme deponun süper kullanıcısıyla

Yükseltme sayfası (UPGRADE, UPGRADE LEVEL; önizleme hariç) Firebird / PostgreSQL / ODBC veritabanında deponun süper kullanıcısıyla koşar: kullanıcı adı (öndeğer sysdba) ve parola sayfanın üstündeki Depo süper kullanıcısı alanına girilir; alan yalnız bu depolarda görünür, parola boşsa yükseltme başlamaz. Parola her yükseltmeden önce aynı oturuma SET STORAGE CREDENTIALS ile verilir ve ardından silinir — ne kayda, ne günlüğe, ne SQL izine girer; depo reddederse alan boşaltılır. Yedek ve bütün yazımlar bu kimlikle ayrı bir bakım bağlantısında koşar; yanlış parola yükseltmeyi başlatmadan reddeder. SYSDBA ile açılmış bir oturum kimlik vermezse kayıttaki servis kullanıcısıyla koşar; başka bir login kimlik vermeden yükseltme başlatamaz.

4.4.6 Oturumun kendi kimliğiyle depo bağlantısı (Session Authentication)

Kayıttaki User Name/Password öndeğerde her oturumun depo kimliğidir: yönetim arayüzünün SQL sayfası, msql, FireDAC sürücüsü ve MCP ile gelen her istek depoya bu (genelde süper kullanıcı) kimlikle gider, IVEDI'nin hakları onun üstünde uygulanır. Bağlantı dizesine Session Authentication=Yes yazılırsa login'li bir oturumun depo bağlantısı o login'in kullanıcı adı ve oturum açarken verdiği parolayla kurulur; kayıttaki kimlik yalnız ajanın kendi iç bağlantılarında (katalog yükleme, zamanlayıcı) ve SYSDBA oturumlarında kalır. Depoda aynı adlı ve aynı parolalı bir kullanıcı/rol bulunmalı ve hakları orada verilmiş olmalıdır (GRANT zaten depoya yansıtılır); depo kendi haklarını uygular, IVEDI'de SYSADMIN olmak depoda hak kazandırmaz. Ayrıntı ve ad katlama kuralları SQL kılavuzunun "Oturumun kimliğiyle depo bağlantısı" bölümündedir.

open database NETSIM storage engine postgresql
  parameters 'Server Name=localhost; Database Name=netsim; User Name=netsim_svc; Password=***;
              Catalog Schema=netsim; Session Authentication=Yes';

4.4.7 Kimlik bilgisini ortam değişkeninden almak

Kullanıcı adı ve parola bağlantı dizesinden tümüyle çıkarılabilir. O zaman kimliği istemci kütüphanesi kendi ortam değişkenlerinden okur — bu, ajanın değil sağlayıcının davranışıdır, dolayısıyla değişken adları sağlayıcıya göre değişir:

Üç istemci sağlayıcısından ikisi seçeneği tanır. Aşağıdaki tablo istemci tarafında ne değiştiğini ve sunucu tarafında neyin yapılandırılmış olması gerektiğini verir; ikincisi olmadan seçenek yalnızca bağlanmayı engeller:

Tanı sırası şu iki davranışı bilmeden yanıltıcıdır:

• Veritabanı bağlantısı açılışta kurulmaz, ilk kullanımda kurulur. Ajanın temiz açılması bağlantı dizesinin doğru olduğunu göstermez; yanlış bir dize ya da eksik bir eşleme kendini ilk istekte gösterir. Bağlantıyı sınamanın en kısa yolu, hizmeti başlattıktan sonra o veritabanına giden bir istek atmak ve günlüğe bakmaktır.
• Database Name'deki göreli bir ad bir dosya olmak zorunda değildir: Firebird'de aynı ad sunucunun databases.conf'undaki bir takma ad olabilir ve bambaşka bir yoldaki dosyayı gösterebilir. "Dosya yok" diye aramaya başlamadan önce oraya bakın.

Hizmetin hesabını -INSTALL -SERVICE_USER ile vermek gerekir; kurulmuş bir hizmette hesabı sc config <ad> obj= ile değiştirmek yetmez, çünkü o yol SeServiceLogonRight'ı vermez ve başlatma 1069 ile düşer (bkz. 2.2).

Aynı seçenek ajanın kendi MQL motorunda CREATE DATABASE … STORAGE ENGINE yazarken de geçerlidir; orada ODBC motoru da destekler. O yolun ayrıntısı MQL kılavuzunun “Depolama motorları” bölümündedir: IVEDI SQL Kullanıcı Kılavuzu.

4.4.8 Bağlantı havuzu

CRUD uygulamasının kullandığı istemci bağlantıları bir havuzda yaşar: bir istek bitince bağlantı kapatılmaz, açık kalmış transaction geri alınır ve bağlantı havuza döner; aynı işçi sürecin bir sonraki isteği yeniden bağlanmaz. İşçi süreçlerin kendisi zaten havuzlu olduğu için (poolTimeoutMS) bir işçi art arda pek çok isteğe bakar ve bağlantısı onunla yaşar.

Havuzun kaydı süreçler arasıdır, bağlantının kendisi sürece bağlıdır. Havuz nesnesi ve kayıt listesi paylaşılan bellektedir (kontrol bloğunun adlı nesnesi); bütün işçi süreçler aynı listeyi görür, aynı kilidi alır ve MONITORDATA hepsini birden sayar. Her kayıt onu açan sürecin kimliğini taşır ve yalnızca o süreç tarafından kiralanabilir. Nedeni fizik: depolama istemcisinin tutamacı sürece aittir — fbclient'in tutamacı sürecin kendi tutamaç tablosunun indisidir, libpq'nun PGconn'u o sürecin yığınındaki bir işaretçidir. Başka sürecin bağlantısı kullanılamaz da kapatılamaz; ölen bir sürecin kaydı bir sonraki havuz işleminde silinir (orphaned sayacı), nesnesi süreçle birlikte gitmiştir. Usta süreç bir isteği HTTP'yi okumadan işçiye verdiği için “bağlantısı olan işçiye yönlendirme” diye bir şey yoktur: işçi kendi bağlantısını kendi bir sonraki isteğine verir, günlükte Baglanti havuzu: surec N kendi baglantisini yeniden kullaniyor satırı ve MONITORDATA.connectionPool.byProcess bunu gösterir.

Havuzun anahtarı veritabanı adı ve kimliktir (kullanıcı adı + parola özeti): authMode: "database" ile açılmış bir bağlantı yalnızca aynı kullanıcı adı ve aynı parolayla gelen isteğe verilir. sqlite dosyası WAL günlüğü ve normal kilit kipiyle açılır ve havuzlanır: işçiler aynı dosyayı birlikte kullanır, okuyucu yazıcıyı beklemez, yazıcılar Busy Timeout (bağlantı dizgisi, milisaniye, öndeğer 30000) kadar sırayla bekler. :memory: havuzlanmaz; kopmuş bağlantı havuza alınmaz.