Az atipikus konfigurációk frissítése vagy az unalom eltávolítása

Az atipikus konfigurációk frissítése vagy az unalom eltávolítása //

Elkezdem talán azzal, hogy megtanultam frissíteni a nem tipikus konfigurációkat, és mindezek miatt vezetett.

Elkezdtem frissíteni a k-ot a tc 77-ből.

A 7-ke frissítési mechanizmusa nagyon egyszerű. 3 alapot hozunk létre. 1 munkalap, 2. munkadarab másolata, ugyanazon kiadás 3. üres mintaadatbázis.

Összehasonlítom egy új kiadással. Második pedig egy tipikus kiadás. 3yu egy új kiadással.

Összesen az összehasonlítás 2. ablakában látjuk az összes "javítást" a 3. helyen, látjuk az összes változást a kiadás. és főleg döntsük el, mi hagyjuk, és mit veszünk az új kiadásból.

A frissítés után az ellenőrzés: a működő, frissített adatbázis összehasonlítása egy tipikus kiadással történik. A változtatások listájának meg kell egyeznie a második adatbázissal. Ha igen, akkor a frissítés helyesen történik.

A 8ke-ben minden megváltozott.

Kezdve azzal, hogy egy adatbázisban 3 vagy több konfigurációt tárol.

1 - Alap konfiguráció - Az, amelyik a programozó közvetlenül működik.

2 - Adatbázis konfiguráció - Ez a konfiguráció, amelyen az adatbázis jelenleg fut. (pl. ha néhány sort ír a konfigurátorban, az azt jelenti, hogy az adatbázisban az alapkonfiguráció és a konfiguráció nem volt azonos, a másodikban)

3 - A szolgáltató konfigurációja lényegében minta kiadás.

4..n szolgáltatói konfigurációk sokak lehetnek, de ez a téma egy teljesen más cikk.

Ez a tény lehetővé tette a fejlesztők számára egy adatbázisban, hogy egy csomó jószágot valósítson meg. Pontosabb róluk:

1. pont. - Egy adatbázishoz történő frissítéskor láthatja a 3 különbség mindhárom különbségét a fent említett 3 bázisban. (A mintaadatbázis eltérése az új kiadástól, a "Programozók fejlesztéseitől" - az alapkonfiguráció és a szállító konfigurációjának különbségei, valamint az alapkonfiguráció és az új kiadás közötti különbség).

2. tétel. - Elméletileg 3 eset fordulhat elő a frissítés során

1 eset - az objektumot csak az adatbázisban változtatták meg, a kiadásban pedig nem volt változtatás

2 eset - az objektum csak a kiadásban módosul, és az adatbázisban nem különbözik a szállító konfigurációjától

3 eset - az objektum mind ott, mind ott változik.

így a 8. első és a második esetben a platform automatikusan kezeli. (Meghatározza, hogy melyik konfiguráció alapján vegye le a kódot)

1 összefüggés az alapvető konfiguráció prioritásával - (ami még fontosabb, amit a programozók végeznek)

2 integrálása a szállító új konfigurációjának elsőbbségével - (ami még fontosabb a kiadásban)

A kód egyesítésének módjában történt frissítés után sok rekord kerül a címkére // // MRG Itt egy példa egy kódról az Előzetes jelentésből.

Például a kód ezen pontján egyértelmű, hogy a SokrLP () eljárást hozzáadták a kiadáshoz;

A kód ezen a pontján néhány AFM (Andropov Fyodor Mikhalych vagy valaki más)