Mam programy wykorzystujące silnik firebirda 2.5. Jeden z programów przechodzi na firebirda 3.0. Tutaj nie ma problemów z bazami. Hasła są zapisywane w bazie security2.fdb. Ale drugi program ma hasła użytkowników i administratora (admin) zapisane w specjalnej bazie (USERGROUP) i tylko tam. Nie ma ich w bazie security2.fdb. O ile z tą bazą (USERGROUP) pod firebirdem 2.5 można się połączyć na przykład za pomocą Fenixsql, i użytkownika SYSDBA, to po przetworzeniu jej na ODS:12.0 już z tą bazą połączyć się nie można. Ani za pomocą SYSDBA ani hasła admina.
Przypuszczalnie hasło admina (i pozostałych użytkowników) zostało po konwersji zmienione. Zagadką jest, dlaczego nie działa też hasło użytkownika SYSDBA
Silniki Firebirda działają na Linuksie.
Co można zrobić w takim przypadku? Z producentem jest utrudniony kontakt.
Jest fajna, obszerna książka o migracji Firebirda, migrowałem z 2.1 i 2.5 do 3.0
https://www.firebirdnews.org/migration-guide-to-firebird-3/
Przepraszam za krótki komentarz, mało konkretny, zajmowałem się tym 2 lata temu i nie pamiętam dokładnie, pamiętam, ze to było tam opisane.
itou123 napisał(a):
Jest fajna, obszerna książka o migracji Firebirda, migrowałem z 2.1 i 2.5 do 3.0
https://www.firebirdnews.org/migration-guide-to-firebird-3/
Przepraszam za krótki komentarz, mało konkretny, zajmowałem się tym 2 lata temu i nie pamiętam dokładnie, pamiętam, ze to było tam opisane.
Generalnie migrację mam opanowaną. Ale ten mój przypadek jest szczególny. Właśnie połączyłem się z producentem i... rozłożył ręce. Hasło użytkownika SYSDBA powinno działać, a nie działa.
EDIT: Jest jakiś postęp. Połączyłem się z bazą użytkowników i haseł. Niestety, konwersja psuje bazę. Wszystkie tabele są puste.
Edycja następna: Baza pierwotnie została zrobiona na wersję Firebirda 2.1. Jest użytkowana na wersji 2.5.
Co prawda robiłem kopię programem gbak i potem z kopii przywracałem, ale to być może powinna być zrobiona kopia na wersji 2.1 i przywrócona wersją 2.5. Nie wiem jaki jest ODS tej bazy. Jak to sprawdzić?