Witam,

W związku z wymianą serwerów muszę przenieść bazę Subiekta GT 1.25 z SQL 2005 Standard na 2014 Express.

Problem pojawia się przy użytkowniku "sa". Do tej pory Subiekt chodzi na bazie, gdzie "sa" nie ma hasła (puste). SQL 2014 nie pozwala na utworzenie instancji z pustym hasłem dla "sa", z kolei Subiekt nie potrafi sie zdearchiwizować z bazy, gdzie nie było tego hasła do bazy, gdzie takie hasło jest (tak wynika z logów).

Obecnie poszukuję informacji, jak zainstalować SQLa w trybie CHECK_POLICY OFF, żeby można było ustawić puste hasło dla "sa", ale może ktoś w międzyczasie podpowiedziałby, jak przeprowadzić dearchiwizację przy takiej niezgodności haseł?

P.S.
Log z serwera:
2014-07-17 14:38:54  Logon  Login failed for user 'sa'. Reason: Password did not match that for the login provided. [CLIENT: <named pipe>]

W związku z wymianą serwerów muszę przenieść bazę Subiekta GT 1.25 z SQL 2005 Standard na 2014 Express.

Zamieniasz wersję "Standard" na "Express" ? Jaki to ma sens ? Na pewno wiesz co robisz, jak ktoś wydał tyle na Standard to chyba była jakiś powód ?

Nie znamy powodów takiej decyzji, a dużo lepszym rozwiązaniem byłoby postawić dwie maszyny lub zrobić downgrade do WS 2008 R2, aby zachować pełnego SQL'a.

Pozostaje jeszcze ostatnie moje pytanie, już robiłem downgrade'y baz danych przez nieprzemyślane decyzje.

Cytat: Aldo w Lipiec 17, 2014, 17:21:53

przy instalacji podać hasło dla sa, a później z poziomu SQL Managera wyczyścić hasło.

Ostatecznie tak właśnie zrobiłem. Niestety, jest kolejny error. Jeszcze bardziej "niestety", tym razem nie ma żadnych informacji w logach co jest nie tak. Po prostu błąd przy samym końcu importu archiwum i już.

No ale jaki dokładnie błąd ? SSMS zwraca wszystkie błędy...

Cytat: dkozlowski w Lipiec 17, 2014, 17:47:46

Zamieniasz wersję "Standard" na "Express" ? Jaki to ma sens ?

Przez jakiś czas, jako serwery zapasowe będą wykorzystywane stare serwery, które nie udźwigną wersji Standard. Już teraz ledwo chodzą na 2005 Standard. Wersja express jest jednak lżejsza i mniej zasobożerna.

Delikatnie mówiąc nie mam zielonego pojęcia o czym piszesz ? Przecież właśnie o to chodzi, aby SQL pobierał jak najwięcej "zasobów", gdyż wtedy może wydajniej pracować ?

Cytat: birds22 w Lipiec 17, 2014, 19:20:24

Chyba jedynym sensownym wytłumaczeniem jest posiadanie serwera w wersji 2012 (R2), na którym to wersja 2005 nie jest obsługiwana.

Dokładnie tak

Nie jestem pewien czy przeczytałeś moje pytania i uwagi...

Cytat: dkozlowski w Lipiec 21, 2014, 10:19:35

SSMS zwraca wszystkie błędy...

Możesz podpowiedzieć, jak je stamtąd odczytać?

Chyba nie rozumiem... Aby zobaczyć błąd w aplikacji trzeba jej najpierw użyć - odtwarzałeś w ogóle backup za pomocą SSMS ?

Mamy licencje na WS 2012, nie mamy na 2008, czy inne. Ot całe sedno sprawy.

Ciągle wygląda na to, że nie czytałeś tego co napisałem, dlaczego nie macie licencji na WS2008 (dlaczego nie macie prawa do downgrade'u) ?

Zastanawiam się, czy nie powinienem na wirtualce zainstalować jakiegoś np. trialowego Windowsa, żeby po kolei robić import bazy do coraz nowszych wersji SQL? Może jest zbyt duża różnica między 2005, a 2014? Czy wymyślam?

A nad czym się tu zastanawiać, trzeba wcześniej się dowiedzieć (http://msdn.microsoft.com/en-us/library/ms143393.aspx) i sprawdzić. Jak pisałem wcześniej powrót do niższej wersji jest możliwy, ale skomplikowany.

Dobra, zostawmy kwestie naszych licencji. Nie możemy, nie mamy i mieć nie będziemy. Po prostu korzystamy z MAPS, który nie pozwala na downgrade.

To wiele tłumaczy...

Co do SSMS, to chyba jednak nie zrozumiałem. O jakiej aplikacji SSMS mówisz?

https://www.google.pl/#q=ssms

"Databases->prawy myszy->Restore Database..."

Ciekawa sprawa, archiwizacja/dearchiwizacja nie dziala z zadna baza, 2008-14. Ktos jeszcze mial podobny problem?