Visszaállítás az SQL adatbázis-1c 8
A dinamikus frissítés, míg a megtakarítás konfiguráció repült bázis 1C és nem volt hajlandó menni a konfigurátor módban, így az üzenet „figyelmeztetés. Ha frissíti az adatokat, miután az utolsó szerkezetátalakítás, hiba történt. Ismételjük meg a frissítést?” Ha igen, akkor az üzenet „találták hiányosnak konfigurációs megtakarítás működését. a folytatáshoz meg kell befejezni a műveletet.”, majd a konfigurátor zárva.
Ennek oka az írás ezt a cikket volt a csökkenés a bázis idején is megőrzi a konfigurációt, ha a dinamikus frissítéseket. Úgy tűnik, hogy már sok figyelmeztetett többször - „Ne dinamikus frissítését 8.2”, de néha anélkül, hogy egyszerűen nem lehet csinálni.
Tehát semmi semmi jelét nem baj, de hirtelen során is megőrzi a konfigurációt, 1C hibát generált a sérült Config és biztonságosan zárható legyen. Gondolva, hogy a probléma megoldódik nagyon egyszerűen azt fedezte fel újra a konfigurátor és olvassa el a következő üzenet:
„Figyelmeztetés. Amikor frissíti az adatokat, miután az utolsó szerkezetátalakítás, hiba történt. Ismételjük meg a frissítést?” „Igen, Nem”
Mégis marad egy vidám hangulatban, rákattintottam a „Yes”. 1C-ka kis gondolkodás és adott egy új üzenet:
„Észlelt partway konfiguráció mentését. A folytatáshoz meg kell befejezni a műveletet.”
Megnyomása után az „OK” az ablak zárva volt a konfigurátor. Ekkor kezdtem el gyanakodni, hogy nem minden olyan egyszerű.
Folytatva mélyebbre ásni, idejöttem a nagyszerű cikket VanDiesel1. Ez csak ez a módszer nem működik, ha a bázisok találhatók a különböző csoportosulások, de miután néhány gondolat, még mindig találtam megoldást. A cikk elolvasása után tudtam meg, hogy az egészet a „romlott” és táblázatok dbo.Config dbo.ConfigSave.
Tehát félre pánik!
1. Ellenőrizze, hogy van egy konfigurációs azonos összeomlott. Az én esetemben, volt annyi, mint 4, ahogy a munka révén a tárolási helyzetben. Lehet használni, és nem egészen ugyanaz a konfiguráció, de készüljön fel arra, hogy ha az összes változás kell fizetni (hacsak persze nem kell a tárolási konfiguráció).
2. Ezután bemegy az SQL Management Studio és egyértelmű táblák és dbo.Config dbo.ConfigSave összeomlott bázis segítségével egy egyszerű kérés (annak érdekében, hogy írja meg, kattintson az „Új lekérdezés” vagy „Új lekérdezés”, nos, hogy végre - az „Execute” és a "Run", sorrendben):
Csonkolása asztal dbo.Config
Csonkolása asztal dbo.ConfigSave
3. Minden, ami már elhagyta a „töltse ki a” ugyanannál az asztalnál egy jó konfigurációt. Mint korábban írtam, az eljárás által javasolt VanDiesel1 nem segít nekem, mint egy működő alap és minden bázisok jó konfigurációk különböző csoportosulások. Miután elolvasta a kézikönyvet, hogy az SQL Management Studio. Belebotlottam ez a lehetőség az import táblák egyik adatbázisból a másikba, és azonnal úgy döntött, hogy használja azt. Így az SQL Management Studio károsodásához adatbázis és jobb klikk, majd Feladatok -> Adatok importálása.
Ez megnyitja a varázslót, amelynek során:
- a) A második oldalon, adja meg a szerver és az adatbázis, ahonnan vesszük az adatokat.
- b) jelzi a harmadik bázist vevő.
- c) A negyedik válassza ki a „Copy adatokat egy táblázatba.”
- d) Az ötödik veszi jackdaws táblázatban dbo.Config és dbo.ConfigSave.
- e) A hatodik keres a hibák elkerülése és a boot folyamat sikeres.
4. Ez minden, akkor próbálja meg futtatni az 1C.
Ui Ennek során a megoldás arra, hogy elismerik ezt a helyreállítási módszert nem dokumentált 1C és minden olyan tevékenységet csinálni a saját kockázatára, és dokumentált módon - visszaállítja a biztonsági másolatból.
10. Early Bird féle (Earlybird) 1 21/07/13 00:18 Most a témában
1. Ellenőrizze, hogy van egy konfigurációs azonos összeomlott. Az én esetemben, volt annyi, mint 4, ahogy a munka révén a tárolási helyzetben. Lehet használni, és nem egészen ugyanaz a konfiguráció, de készüljön fel arra, hogy ha az összes változás kell fizetni (hacsak persze nem kell a tárolási konfiguráció).
2. Ezután bemegy az SQL Management Studio és egyértelmű táblák és dbo.Config dbo.ConfigSave összeomlott bázis segítségével egy egyszerű kérés (annak érdekében, hogy írja meg, kattintson az „Új lekérdezés” vagy „Új lekérdezés”, nos, hogy végre - az „Execute” és a "Run", sorrendben):
Csonkolása asztal dbo.Config
Csonkolása asztal dbo.ConfigSave
3. Minden, ami már elhagyta a „töltse ki a” ugyanannál az asztalnál egy jó konfigurációt. Mint korábban írtam, az eljárás által javasolt VanDiesel1 nem segít nekem, mint egy működő alap és minden bázisok jó konfigurációk különböző csoportosulások. Miután elolvasta a kézikönyvet, hogy az SQL Management Studio, belebotlottam ez a lehetőség az import táblák egyik adatbázisból a másikba, és azonnal úgy döntött, hogy használja azt. Így az SQL Management Studio károsodásához adatbázis és jobb klikk, majd Feladatok -> Adatok importálása.
Ez megnyitja a varázslót, amelynek során:
a) A második oldalon, adja meg a szerver és az adatbázis, ahonnan vesszük az adatokat.
b) jelzi a harmadik bázist vevő.
c) A negyedik válassza ki a „Copy adatokat egy táblázatba.”
d) Az ötödik veszi jackdaws táblázatban dbo.Config és dbo.ConfigSave.
e) A hatodik keres a hibák elkerülése és a boot folyamat sikeres.
4. Ez minden, akkor próbálja meg futtatni az 1C.
37. Andrey dyak (dyak84) 23.07.13 17:19 Most a témában
38. Peter Surenko (lord_soth) 276 23/07/13 17:28 Most a témában
11. Early Bird féle (Earlybird) 1 21/07/13 00:21 Most a témában
12. Eugene (WanGoff) 123 21/07/13 01:57 Most a témában
13. Early Bird féle (Earlybird) 1 21/07/13 02:43 Most a témában
dolgozó helyzetet, ha a programozó 1C nem fogja megoldani ezt a problémát külső segítség nélkül -, hogy ő nezachOt.
18. Eugene (WanGoff) 123 21/07/13 14:20 Most a témában
14. Peter Surenko (lord_soth) 276 07/21/13 10:28 Most a témában
(12) WanGoff, a felelősség a programozó 1C a nagy kiadók nem tartalmazza az adatbázis adminisztráció, és még inkább, hogy nem férnek hozzá a szerverek.
(7) Gilev.Vyacheslav, kösz a linket, de a felette kellene segíteni? A helyes válasz - semmi.
17. Vjacseszlav Gilyov (Gilev.Vyacheslav) 1756 7/21/13 14:19 Most a témában
(14) lord_soth, lásd 7.7
19. Peter Surenko (lord_soth) 276 21/07/13 16:14 Most a témában
(17) Gilev.Vyacheslav, az a tény, a kérdés az, hogy a konfiguráció nem is közel a standard, úgy, hogy 7,7 nem alkalmas.
15. Alex Bochkov (Aleksey.Bochkov) 2775 7/21/13 11:43 Most a témában
(0) Mindig segítve más, kevésbé fájdalmas módon - távolítsa el a két bejegyzés a táblázatban a konfigurációs:
20. Vjacseszlav Gilyov (Gilev.Vyacheslav) 1756 7/21/13 19:32 Most a témában
de egy pár év, és akkor találkoznak az idő, ha elolvasta a következő „feltaláló” írt itt, az egész történet alakul ki egy kört.
21. Peter Surenko (lord_soth) 276 21/07/13 19:48 Most a témában
a történet alakul ki egy kört.
(20) Gilev.Vyacheslav, igazad van, és tényleg, ne menjünk tovább.
22. Vladislav Svintsov (VSvintsov) 13 21/07/13 20:32 Most a témában
23. Peter Surenko (lord_soth) 276 21/07/13 22:17 Most a témában
(22) VSvintsov, de most úgy döntött, hogy egy példányt a szalagot. )
24. Alexander Milutin (sanfoto) 470 22/07/13 06:36 Most a témában
De mivel a motor 8.2.17 kiadás (ellenőrizze kezdve 8.2.17.169) - mindez nem Fidler. hibák elment!
25. Peter Surenko (lord_soth) 276 07/22/13 06:59 Most a témában
(24) sanfoto, mi csak volt 8.2.16. (Hogyan ellenőrzik? Van bizonyíték 1C?
29. Alexander Milutin (sanfoto) 470 22/07/13 12:02 Most a témában
mi történt a 8.2.16. (Hogyan ellenőrzik?
A papír teszteltük, mint a még)), és így, mint a hivatalos volt írva, hogy a határozott démoni frissítés 8.2.17.
Néhány hónappal 8.2.17.169 - Dinamikus (nem nevezhető démoni) frissítéseket (több csalók) nagyon gyakori - hibák a összegyűjtése a konfiguráció egyáltalán nem.
PS:
Közvetlenül a központi adatbázisban nem írok semmit - egész „Storage Configuration”. mindegyiknek megvan a saját adatbázisa progeria.
30. Peter Surenko (lord_soth) 276 22/07/13 12:32 Most a témában
28. Sergey Gukov (SirYozha) 172 07/22/13 11:41 Most a témában
(24) is érdekelt, hogyan ellenőrzik? )
26. Andrey Konev (Infector) 93 22/07/13 8:58 Most téma
Egy kicsit több a témában - talán csak véletlen egybeesés, de észrevettem egy érdekes dolog - ha mielőtt a dinamikus frissítési konfiguráció megtakarítás (Ctrl + s, csak akkor F7) valószínű probléma az adatbázis kezelése kevésbé élesen - sikeresen távolítson el minden felhasználó és frissíteni az adatbázist mágia nélkül az SQL
27. vicmos victor (vicmos) 40 22/07/13 10:09 Most a témában
Köszönöm a megoldás egyszerűen és ízlésesen.
31. Andrey Konev (Infector) 93 22/07/13 12:55 Most a témában
8.2.17.hhh nem csodaszer, esik, de sokkal ritkábban. Tehát ne felejtsük el, hogy a mentést a frissítés előtt.
32. Alexander Milutin (sanfoto) 470 22/07/13 13:08 Most a témában
Tehát ne felejtsük el, hogy a mentést a frissítés előtt.
Miért BekapKazhdy nappali? kivéve, ha esik táblázat konfiguráció.
ha az ilyen lehetőséget, akkor tegye, mint a (24) sanfoto, azaz Nepishi közvetlenül a központi és yuazaem „Configuration Repository”, vagy írjon kódot a „külön adatbázis”.
PS:
Bár mentések Mindegy tettünk))
1) A teljes mentés naponta egyszer -
2) és a Tranzakshen-log óránként. ECHO összes automatikus))
PS2:
A program működik 24/7 nincs menekülés - kivéve a dinamikus frissítéseket - az érintettek által a indítsa újra a programot (vagy mi vagyunk „rászorultak” help újraindítás)))).
42. Eugene (Evmil) 13 06/08/14 12:42 Most a témában
(31) Infector, ha a dinamikus frissítés az alap repült, akkor aztán elűzi tagjai folyamatosan frissítésével monopólium, és minden rendben van a platform> 8.2.16.
33. Andrey Konev (Infector) 93 22/07/13 13:19 Most a témában
Nagyjából, a legfontosabb dolog, hogy tartsa a biztonsági konfigurációt, mielőtt a változás nem olyan sértő volt része izmeneneny elveszíti a várható fellendülés. Ha az éjszakai mentés mindent, ő természetesen elégedett.
PS: a konfigurációs adattár még nem elég érett.
35. Gennagyij Zimin (Kenzával) 22.07.13 15:48 Most a témában
(33) Infector, egyetért. Folyamatosan teszteli konfigurációs változások lokálisan, majd kitölteni egy újat. A régi konfiguráció szintén mentésre kerül. Dinamikusan frissíti az összes nem használható, mivel már győződve arról, hogy ez nem jó nem)
34. diver.sun diver.sun (diver.sun) 22 22/07/13 15:15 Most a témában
Szembesülve ugyanez a helyzet, ha a vezeték nem dinamikus és a szokásos frissítés, és meghalt HASP szerver. megkerülte a probléma a következő: Tiszta az asztalra configsave majd rendezni a táblázat config, és nézd, hogy megváltozott az utolsó volt valamiféle rekord attribútumot. a neve az élet nekem nem emlékszik. ez több volt, mint a módosítás dátuma adatrögzítés. és a mérete nulla, azt el kell hagyni, és a bázis általában elfelejtette, hogy ő akarta, hogy frissíteni kell
36. Alexey Soloviev (Silenser) 433 07/23/13 11:45 Most a témában
Tény, hogy egyszer is elég, hogy írjon egy forgatókönyvet, ami hát 2 tabletta konfitált új lemezekre ugyanazon adatbázis segítségével válassza a. Ha futtatni frissítése előtt állomány dinamikájának megoldott 1 percig. Könnyebb megelőzni, mint gyógyítani;)
39. Marina Cirino (chmv) 24.07.13 12:38 Most a témában
40. Oberonm (oberonm) 9 07/30/13 11:37 Most a témában
41. Michael Cher (mmch) 119 14/08/13 13:15 Most a témában
Én nem hiszem, hasznos és praktikus ma! Köszönöm, munkamódszer, ellenőrzött személyesen =)