Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: bodek_kocio w Kwiecień 25, 2014, 20:26:50
-
Jak w tytule. Kupiłem nowy dysk SSH i przekopiowałem do niego cały folder SQL. Podłączenie bazy danych z nowego folderu poprzez program serwisowy daje komunikat "podmiotu nie podłączono". Ze "starego" folderu działa podłączenie innych podmiotów. Archiwizacja również nie przynosi spodziewanego efektu, Kopiowanie tak samo. Zmiana ścieżek dostępu w SQL Server Conf. Manager powoduje zatrzymanie serwera SQL (może nie wszystko zrobiłem jak należy ?). Przekopałem pół internetu i tego forum i nie znalazłem odpowiedzi. Jak zrobić przeniesienie bazy reinstalacji programu?
Korzystam z Inserta 1.34 SP3 (Subiekt i Gestor).
-
1. Program serwisowy - odłącz podmiot
2. Przeniesienie plików bazy
3. Program serwisowy - podłącz podmiot
-
Gdyby to było takie proste to nie pisałbym. Napisałem że nie można podłączyć bazy na innym dysku niż w moim przypadku "D" , a nowy dysk to "H"
-
Uprawnienia ?
Spróbuj podłączyć za pomocą SSMS i zobacz jaki jest błąd.
-
Jakąś podpowiedź? Słaby jestem w SQL...
-
Wydaje mi się, że błąd leży gdzie indziej. Pytającyna pisał, że przekopiował cały SQL na nowy dysk - przekopiował, a nie zainstalował na nowym dysku. W zwiazku z tym ten serwer jest nieaktywny i tyle. Serwer SQL trzeba na tym dysku zainstalować i dopiero przekopiować pliki baz danych. Wtedy bedzie aktywny i dadzą się podłaczyć.
Chyba, że serwer SQL ma pozostać na dysku c tak jak był. a same pliki baz danych przenieść na na nowy. Wtedy przy podłączaniu trzeba podać ścieżkę do plików na nowym dysku.
-
Jakby nie działał SQL Server to nie uruchomiłby programu serwisowego.
Mam nadzieję, że nie chcesz podłączyć bazy z innej lokalizacji wybierając nadając nazwę jak baza już podłączona?
SSMS to SQL Server Management Studio, tam możesz podłączyć bazę. Proponuję jednak przenieść pliki bazy do folderu np H:\Bazy\ , i ustawić uprawnienie takie jak na tych plikach pierwotnych.
-
Czy nie da się korzystać z serwera który jest zainstalowany np. na dysku D: a baza danych na dysku H:? Jak zmienić ścieżki dostępu w serwerze SQL aby wskazywały na nową lokalizację pliku (plików)? Czy Jednak jak przedmówca napisał wszystko musi być w jednej lokalizacji? Jak w takim razie "sklonować" taki serwer na inny dysk?
-
Serwer śmiało może zostać na dysku D.
-
Widzę że "zielony jestem jak trawa na wiosnę". Birds o jakich uprawnieniach mówisz? Zmieniałem nazwy baz i to w pierwotnych lokalizacjach jak i w nowej. Chyba że sama zmiana nazwy podczas podłączania nie ma większego znaczenia i trzeba zmienić nazwy plików? Próbowałem również na kilku bazach nie tylko tej "głównej" ale na bazie testowej "nowy". Na dysku d:/... /data/ podłącza się i odłącza każda baza, natomiast jak wskazuję te same pliki z dysku h:/.../data/... to otrzymuję komunikat jak na obrazku "baza nie została podłączona". Serwer SQL działa jednak wskazuje tylko na pliki w swoim katalogu D:/.../data/... .
-
Może lepiej poprosić jakiegoś informatyka?
Mówiąc o uprawnieniach, mam na myśli uprawnienia dostępu do plików bazy danych (właściwości pliku).
Nie chodzi mi o zmianę nazw plików bazy danych. W programie serwisowym podłączając bazy wskazujesz plik mdf i wpisujesz nazwę podmiotu (alias). I własnie ta nazwa nie może być taka jak już używana.
-
Przy starszych SQL taką operację dawało się wykonać bez problemu. Teraz próbuję na SQL 2008R2 i niestety żadnej bazy położonej w innej lokalizacji poza folderem serwera SQL nie daje się podłączyć. Nawet położonej w innym folderze na dysku C. Chyba jednak trzeba będzie zainstalować SQL na dysku H.
-
Ja własnie podłączyłem.
-
O informatyku pomyślałem już. :) Ale wymiękł ..., gdyż akurat całą sprawa zaczęła się od padniętego zasilacza w tym komputerze i jego wymianie w sklepie, gdzie zaproponowali mi dodatkowy dysk SSD. Chyba tylko serwisant Inserta poradzi sobie z tym. Aliasy zmieniałem i nie pomagało. O uprawnieniach plików też myślałem (pomyślałem teraz że piszesz o jakiś innych o których nie wiem). Chociaż sprawdzę je jeszcze raz. Widzę że najprostszym rozwiązaniem będzie odinstalowanie całego Inserta i ponowna jego instalacja w nowej lokalizacji. Gdybym to od razu zrobił to po godzinie wszystko by "śmigało". Widać nie jest to takie proste jakby mogło się wydawać.
Birds napisz jak to zrobiłes... Łopatologicznie proszę... :) Może z jakimis obrazkami?
-
Odinstalowanie Inserta nic Ci nie da, taką operację trzeba ew, zrobić na SQL.
-
Ja własnie podłączyłem.
Możesz podać szczegóły, bo ja ni cholery nie mogę.
-
nie myl oprogramowania Insert z Microsoft SQL Serverem
zobacz czy mozesz podlaczyc baze z innej lokalizacji z poziomu SQL Server Management Studio
-
W okolicy tylko jeden informatyk?
1. Odłączyłem plik podmiotu w programie serwisowym
2. Przeniosłem pliki podmiotu (podmiot.mdf, podmiot_log.ldf) do nowej lokalizacji (u mnie E:\Bazy\)
3. W każdym z plików zmieniłem uprawnienia dla Użytkownicy na pełny dostęp
4. Podłączyłem pliki w programie serwisowym.
Do tego chyba obrazków nie trzeba?
Środowisko:
SQL Server 2008R2 Express
Win8
-
Ja własnie podłączyłem.
Możesz podać szczegóły, bo ja ni cholery nie mogę.
Już wiem - wybrałem pliki podmiotu z archiwum i nie dość, że to stara baza, to jeszcze uszkodzona. Dlatego nie chciał podłaczyć.
Inne prawidłowe dają się bez problemu z dowolnej lokalizacji - ale lokalnej.
-
bird jesteś wielki.
Wiem gdzie błąd zrobiłem. Uprawnienia sprawdzałem na folderze nie na plikach. Teraz zrobiłem na plikach i działa. Dziekuję bardzo wszystkim aktywnym...
-
Pozwolę sobie odświeżyć temat...
Przeniosłem swoją bazę danych na inny dysk (brak miejsca na systemowym) i wszystko śmiga OK. Jednak przy aktualizacji oprogramowania, gdy robi aktualizację bazy to zaktualizowana jest w nowej lokalizacji, a kopia starej bazy tworzy się w starej lokalizacji na dysku systemowym. Nigdzie nie mogę znaleźć, gdzie podmienić lokalizacje kopii starej bazy by tworzyła się także w aktualnej nowej lokalizacji. Niby mały problem, ale jak baza ma 23GB to po paru aktualizacjach robi się brak miejsca na dysku systemowym. Co aktualizacja muszę odpinać i przenosić kopię w inne miejsce.
Może ktoś pomóc?
-
Problem znany i stary jak GT - należy na nowo zainstalować serwer SQL w oczekiwanej lokalizacji.
-
Przeniosłem swoją bazę danych na inny dysk (brak miejsca na systemowym) i wszystko śmiga OK. Jednak przy aktualizacji oprogramowania, gdy robi aktualizację bazy to zaktualizowana jest w nowej lokalizacji, a kopia starej bazy tworzy się w starej lokalizacji na dysku systemowym. Nigdzie nie mogę znaleźć, gdzie podmienić lokalizacje kopii starej bazy by tworzyła się także w aktualnej nowej lokalizacji. Niby mały problem, ale jak baza ma 23GB to po paru aktualizacjach robi się brak miejsca na dysku systemowym. Co aktualizacja muszę odpinać i przenosić kopię w inne miejsce.
Może ktoś pomóc?
A zobacz Sobie co masz we właściwościach Files tych baz danych jako ścieżki do plików (np. za pomocą SSMS) - czy są prawidłowe? Bo zwykłe odtwarzanie kopii z innej lokalizacji w nowej lokalizacji bez opcji "relocate all files to folder" czy jakoś tak (a pakiet InsERTa to robi chyba bez tej opcji) zostawia stare ścieżki i może dlatego kopia tworzy Ci się w starej lokalizacji?
-
Jak napisałem to dobrze znany problem, pakiet Insertu nie odczytuje lokalizacji plików z konfiguracji serwera SQL tylko tworzy je na podstawie folderu instalacyjnego.
-
Jak napisałem to dobrze znany problem, pakiet Insertu nie odczytuje lokalizacji plików z konfiguracji serwera SQL tylko tworzy je na podstawie folderu instalacyjnego.
To dziwne. Gdy przeniosłem (bez reinstalacji pakietu) bazy na serwer linuksowy, to kopie robił w dobrym miejscu. Choć i tak trzeba je było poprawiać, bo InsERT GT psuje w nich przedmiotowe ścieżki (wstawia /\ w miejsce /) i pomija rozszerzenia nazw plików. Ale może dlatego robi w dobrym miejscu, że zostawiłem domyślne ustawienia na serwerze.
-
Jak napisałem to dobrze znany problem, pakiet Insertu nie odczytuje lokalizacji plików z konfiguracji serwera SQL tylko tworzy je na podstawie folderu instalacyjnego.
To dziwne. Gdy przeniosłem (bez reinstalacji pakietu) bazy na serwer linuksowy, to kopie robił w dobrym miejscu. Choć i tak trzeba je było poprawiać, bo InsERT GT psuje w nich przedmiotowe ścieżki (wstawia /\ w miejsce /) i pomija rozszerzenia nazw plików. Ale może dlatego robi w dobrym miejscu, że zostawiłem domyślne ustawienia na serwerze.
Nie odniosę się do zachowania programu z serwerem SQL na linuksie, gdyż nie mam doświadczeń w tym obszarze.
-
Nie odniosę się do zachowania programu z serwerem SQL na linuksie, gdyż nie mam doświadczeń w tym obszarze.
Działa prawie dobrze (to prawie osobom nieobeznanym może robić poważny problem), powiedziałbym wydajniej niż na Windows. Robi tylko następujące numery: przy aktualizacji we właściwościach w kopiach baz psuje ścieżki plików wstawiając /\ zamiast / i nie daje rozszerzeń plików - co dziwne i InsERT i MS SQL z takimi ścieżkami i nazwami plików działają... InsERT dopiero wywala się na tym przy próbie aktualizacji baz z tak skopanymi ścieżkami we właściwościach. Po ręcznym poprawieniu tego jest OK. I do tego trzema mieć SSMS 18.5, bo wcześniejsze też nie radzą sobie z kierunkiem ukośników...
Przy aktualizacji na linuksowym serwerze nie czyści katalogu tymczasowego z kopii baz - też trzeba kasować ręcznie by nie zapchać dysku.
Reszta jest OK: jeśli katalog roboczy do wykonywania backupów narzędziem InsERTa ustawi się jako udział samby tak samo widziany przez Windowsowych klientów i serwer linuksowy. Ale jak ktoś tego nie używa do robienia backupów to nawet nie musi tego ustawiać.