1C:Enterprise 8.3'te grup yapılandırması geliştirme için şunu kullanın: yapılandırma deposu. Geliştiriciler, yapılandırma deposuna şu yollarla erişebilir: yerel ağ(veritabanı dosyaları paylaşılan bir ağ kaynağında bulunur), protokole göre tcp veya http. Son iki seçenek kurulum gerektirir yapılandırma depolama sunucusu. Yapılandırma depolama sunucusu sırayla ağ hizmeti, varsayılan olarak "dinleme" bağlantı noktası 1542 ve istemci uygulamalarının (yapılandırıcı) yapılandırma depolama veritabanı ile etkileşiminin sağlanması. Bir hizmet, birden çok yapılandırma deposuna hizmet verebilir. 1C:Kurumsal yapılandırma depolama sunucusunu yükleme hakkında 8.3 (sürüm için geçerlidir 8.2 ) işletim sisteminde Windows aileleri(mevcut örnekte - ) ve bu makalede ele alınacaktır.

1. Yapılandırma deposunun veritabanı dizinini ayarlama

Konfigürasyon Deposu Sunucusu, depo veritabanı dosyalarının yerleştirileceği aynı bilgisayara kurulmalıdır. Bu nedenle öncelikle sunucunun hizmet vereceği tüm depoların dosyalarının tutulacağı sunucunun merkezi dizinini belirleyeceğiz. verilen sunucu. Bu makale bir dizin olsun C:\1C_BASE\deposu\. Ayrıca bir hesap tanımlamanız gerekir Windows girişi, altında ilgili hizmetin başlatılacağı. Mevcut bir Windows hesabı oluşturabilir veya kullanabilirsiniz. Bu örnekte kullanacağımız yerel kullanıcı USR1CV8şifre ile UsrPass8. İçin gerekli bu kullanıcı yapılandırma havuzu sunucusunun merkezi dizinine.

2. Yapılandırma Depolama Sunucusu Dosyalarını Yükleme

Yazma sırasında, yapılandırma deposu sunucusu yalnızca 32 bitlik bir uygulama olarak mevcuttu. Bu nedenle, sunucu dosyalarını yüklemek için Windows için 1C:Enterprise 8.3'ün 32-bit dağıtım setine ihtiyacınız vardır. dosyayı çalıştırın 1CEKurumsal 8.msi teslimat 1C dağıtım kitinden. Bileşen seçim sayfasında bileşeni seçin " Yapılandırma depolama sunucusu 1C:Kurumsal» (1C:Kurumsal yapılandırma veri havuzu sunucusu) ve ayrıca bileşenin kurulum yolunu da unutmayın.

3. Yapılandırma Deposu Sunucusu Hizmetinin Kaydedilmesi ve Başlatılması

Yükleyici, yalnızca yapılandırma deposu sunucu dosyalarını belirtilen dizine kopyalar. İlgili hizmetin kaydı, formun bir komutu yürütülerek manuel olarak yapılmalıdır:

Crserver.exe -instsrvc | -rmsrvc -usr<пользователь>-pwd<пароль>-başlangıç ​​| -durdur -port<порт>-d<каталог>

Yapılandırma Deposu Sunucusu Başlatma Seçenekleri crserver.exe benzer:

1C:Kurumsal Yapılandırma Depo Sunucusu Başlatma Parametreleri

Parametre	Tanım
-Liman<порт>	Depolama sunucusu çalışma bağlantı noktası. Varsayılan bağlantı noktası 1542 .
-d<каталог>	Yapılandırma havuzları için kök dizin. Varsayılan dizin %APPDATA%\1C\1Cv8\.
-instsrvc	Depolama sunucusunu bir hizmet olarak kaydetme.
-rmsrvc	Depolama sunucusunun bir hizmet olarak kaydının silinmesi.
-usr<имя> -pwd<пароль>	Hizmetin adı altında kaydedileceği kullanıcının adı. Bu kullanıcının bir hizmet olarak oturum açma hakkına sahip olması gerekir. Ek olarak, ilgili 1C:Enterprise sürümünün yürütülebilir dosyalarının dizinini okuma haklarına ve yapılandırma deposunun kök dizinine (dizin) tam haklara sahip olmalıdır. %APPDATA%\1C\1Cv8\ veya parametrede belirtilen dizin - d) ve bu kullanıcı için şifre.
-Başlat	Depolama sunucusu hizmetini başlatma.
-Dur	Depolama sunucusu hizmetini durdurun.

Programı kullanarak yeni bir hizmet kaydedin Windows PowerShell'i komutu yürütülerek başlatılabilir güç kalkanı(bunu yapmak için, görünen pencerede Win + R tuş bileşimine basın " Koşmak» (Çalıştır) komutun adını « alanına girin Açık» (Aç) ve « düğmesine basın TAMAM”) veya görev çubuğundaki ilgili kısayola tıklayarak.

Açılan Windows PowerShell konsolunda, daha fazla komut girme kolaylığı için dizine gidin çöp Kutusu katalog yüklü dosyalar 1C:Komutu çalıştırarak işletme

Cd "C:\Program Dosyaları (x86)\1cv8\8.3.5.1088\bin"

Ardından bu örnek çerçevesinde şu komutu yürüteceğiz.

.\crserver.exe -instsrvc -d C:\1C_BASE\repository -usr .\USR1CV8 -pwd UsrPass8

ve çalıştırarak hizmeti başlatın

.\crserver.exe -başlangıç

Servis ek bileşenine gidelim (komutu çalıştırarak başlayabilirsiniz) services.msc) ve hizmetin adlandırıldığından emin olun. 1C:Enterprise 8 Yapılandırma Deposu Sunucusu kayıtlı ve çalışıyor.

5. Yeni bir yapılandırma deposu oluşturun

Daha önce de söylediğim gibi, bir sunucu birden fazla yapılandırma deposuna hizmet verebilir. Depoların her birinin veritabanı dosyaları, yapılandırma havuzu sunucusunun merkezi dizininin ayrı bir dizininde bulunmalıdır. Böylece yeni bir depo oluşturmak için dizinde oluşturacağız C:\1C_BASE\deposu\ dosya Muhasebe yeni yapılandırma deposunun dosyalarını içerecektir.

Ardından oluşturmak ve bağlanmak için bu depo hattı kullanmanız gerekecek tcp://WIN2012/muhasebe, nerede WIN2012— hizmetin yüklendiği bilgisayarın ağ adı veya bir dize tcp://192.168.0.10/hesaplama, nerede 192.168.0.10 , sırasıyla, IP adresi bu bilgisayar. Yeni bir depo oluşturmaya ilişkin ayrıntılar "" makalesinde bulunabilir.

Bu şekilde oluşturulan depolamaya, örneğin yol boyunca sunucuyu atlayarak bağlanmak da mümkün olacaktır. C:\1C_BASE\depo\Muhasebe mevcut bilgisayarda veya yol boyunca \\WIN2012\depo\Muhasebe dizin paylaşımını ayarlarsanız C:\1C_BASE\deposu bu sunucuda.

Bu makale size yardımcı oldu mu?

nefa 647 14.01.10 02:27 şimdi konu başlığında

Makale yararlıdır.
Deponun işleyişinde gerçekten çok açık olmayan şeyler var, bu yüzden benim eklemelerim:
1. Birkaç programcı çalışıyorsa, isteğe bağlı olarak,
Çalışma günü genellikle aşağıdakilerle başlar:
veritabanımızı yapılandırıcıda başlatıyoruz, yapılandırmanın kök dizinine sağ tıklayın - depolamadan alın, "özyinelemeli" onay kutusunu açın, Tamam'a tıklayın. Bundan sonra, başkalarının depodan çalıştığı her şeyi yapılandırmaya giriyoruz. DB'NİN KENDİNİ GÜNCELLEMEYİZ!!!
Ardından, "yapılandırmayı veritabanı yapılandırmasıyla karşılaştırmak" istiyoruz - ve grubun diğer programcıları tarafından önceki gün için yapılan tüm değişikliklerin bir listesini görüyoruz. Değişikliklerle ilgili herhangi bir sorunuz varsa, bunları yapan kişiyle iletişime geçin.
Her şey sıralandıktan sonra veritabanına kaydediyoruz.
Neden depolama yapılandırmasıyla karşılaştırmıyorsunuz - ilk olarak, üzerinde çalıştığınız nesneler gösterilmez ve ikincisi daha hızlı çalışır.
2. Gün ortasında: acil değişiklikler (için dinamik güncelleme) hemen depoya gönderilir. Acil değil - ilgili tüm nesneleri değiştirdikten sonra. (aşağıdaki açıklamaya bakın)
3. Günün sonunda (ve veritabanının tam bir güncellemesini yapmanız gerekiyorsa - ondan önce) mümkün olan her şeyi depoya teslim ediyoruz.
Bu zorunlu değildir, ancak çok uygundur.

4. Neden hemen yerleştirmiyoruz:
çünkü değişikliklerin bütünlüğü sadece bir bağlantının olduğu yerde 1C tarafından kontrol edilir. Yani, örneğin, "Müşterilerin arabaları" dizinini oluşturduysanız ve buna "fatura" bağlantısını eklediyseniz, "Faturayı" yalnızca "Müşteriler" ile birlikte (veya aynı anda) depoya yerleştirebilirsiniz. 'arabalar' dizini. Ancak, örneğin, giden bir fatura gönderirken çağrılan genel modül prosedüründe bu dizini kullandıysanız, bu genel modül dizini yerleştirmeden depoya kolayca sığabilir. Bundan sonra başka bir programcı bu modülü depodan alırsa, faturalar artık veritabanına kaydedilmeyecektir. (Ana üssü güncellerseniz, orada da dururlar).
Ve bu hala iyi bir durum - çünkü sadece bir hata var. Ancak, örneğin, belgedeki öznitelik türünü bir dizeden metne değiştirdiyseniz ve genel modül prosedüründe If Attribute = "1" kontrolü yapıldıysa ve If Attribute = 1 olduysa ve modül içine yerleştirildiyse depo, ancak belge değildi, o zaman hata olmayacak (merhaba, tip kontrolü yok), bu, böyle bir modülü alanların belgelerin yanlış yürütüleceği anlamına gelir (ve bu ana üs değilse iyi olur) . Bu nedenle, değişiklikleri depoya "tam paket" (tüm nesneler bir konuda değiştirildi) halinde göndermek daha iyidir, başka bir görev için bir şeye ihtiyacınız varsa, hemen tekrar yakalayabilir veya yerleştirerek "yakalanmış halde bırakabilirsiniz". depoda.

Bu bağlamda, tam olarak anlamadım:

Çok sayıda programcı varsa, her birinin değişiklikleri birer birer Depoya gönderilmeli, ÖN ÖNCE tüm işleri boşaltılmalıdır. harici dosyalar yerel veritabanının konfigürasyonu ile ve (birleştirme farklı iş istasyonlarından yapılıyorsa), her birleştirmeden önce yerel veritabanlarını Depolamadan GÜNCELLEMEYİ hatırlayarak - En son sürüm, daha önce bağlı olan yoldaşların değişiklikleri ile orada mevcut ..

Garip bir şekilde, birkaç kişi aynı anda değişiklik yaptığında, biraz yavaşlaması dışında hiçbir sorun yoktu. Bu nedenle 2 kişinin aynı şeyi aynı anda düzeltmemesi için nesnelerin yakalanması sağlanır. Ayrıca, şu fark edildi: 1 geliştirici belgeyi değiştirirse, "Gelişmiş rapor" deyin ve ardından ikincisi "almadı", ancak hemen yakaladıysa (örneğin, nesne depoya yeni yerleştirildi), o zaman 1C bunu izleyecek ve ona zaten yeni - değiştirilmiş bir versiyon verecek. (Çok havalı oluyor - belgeye bakıyorsunuz - 5 ayrıntı, yakalıyorsunuz - zaten 15).

Ve neden harici dosyaları boşaltmak için çalışmadığını da anlamadım.

4. Programcılar için veritabanının kopyalarını oluşturmak, 1Sovskaya yükleme ve boşaltma ile değil (çünkü özel bir mod gerektirir ve çok hızlı değildir), ancak bir omurga yedeğini geri yükleyerek veya basitçe elmacık kemiğine tabanı kopyalayarak daha kolaydır.

5. Eklemeniz gerekiyorsa yeni nesne(belge, dizin, vb.), ardından yapılandırma kökünü alın, ekleyin, minimum ayrıntı ekleyin (tamamen "boş" nesneler her zaman kaydedilmez), deponun kökünü kontrol edin (bu nesne de vazgeçilecektir) aynı anda) ve nesneyi tekrar alın. (Kökün uzun süre yakalanmaması için - başkalarının da buna ihtiyacı var).

6. Onu ele geçiren bir nesne üzerindeki izinleri düzeltmek istiyorsanız - ve izinler hala mevcut değilse - uygun rolü alın.

7. Hata ayıklama en iyi en son verilerde yapıldığından, çalışan veritabanlarının güncellenmesi gerekir. Bunu yapmak için: tüm değişiklikleri depoya koyun, veritabanını depodan ayırın, elmacık kemiğindeki ana veritabanının üzerine yazın (yedekten veya kopyalayın), tekrar bağlayın.

8. "Depodan her şeyi al" (s. 1) yaptığımızda, 1'ler bir sürü mesaj verir ve ardından "başarısız" olduğunu yazar (nesnelerin listesi değişir). O yüzden uzun süredir güncellenmiyor. Sorun değil, yenisinde Tamam'ı tıklayın ve olması gerektiği gibi çalışana kadar böyle devam edin.

9. Bazen 1C, depodan alınan değişiklikleri kaydetmeyi reddeder ve mesaj tamamen anlaşılmazdır. Suçlular genellikle "bilgi kayıtları" dır. Yapının hangi bilgi kaydı için değiştiğini buluyoruz, veritabanımızdaki tüm kayıtları siliyoruz, bundan sonra her şey gerektiği gibi güncellenecek.

10. Çalışma tabanları ana tabandan yapıldığından konfigürasyonların isimleri aynıdır ve karıştırılması kolaydır ve daha sonra kullanıcı raporda 100 ruble olduğunu ve 100.000 ruble olduğunu söyleyince yanlış anlamalar başlar. ruble. Alternatif olarak, uygulama modülüne, program başladığında ne tür bir temel olduğunu kontrol eden ve ana değilse, 1C programının başlığında görüntüleyen bir satır ekleriz (örneğin, "PROGRAMCI IVANOV'UN ÇALIŞMA TABANI" ")

11. Veritabanı depolamaya bağlandığında, ancak başlangıçta herhangi bir nedenle ona bağlanmak mümkün olmadığında, "Bağlanamadı, depolamadan bağlantıyı kesin" (ve nesneleri yakaladınız) mesajı görünebilir - burada CEVAP "HAYIR". Ancak yanlışlıkla "evet" cevabını verirseniz - yenisine bağlanmaya çalışmayın !!! İlk önce konfigürasyonu bir dosyaya kaydedin!!! Depolamaya bağlandığımızdan beri, tüm veritabanı yapılandırmasının yerini depolama yapılandırması alıyor. Bundan sonra, kaydedilen dosyadaki değişiklikleri yükler ve daha fazla çalışırız.

Er ya da geç, her geliştirici hayatını iyileştirmeye çalışır. Bu onun maddi bileşeni ile ilgili değil, işi basitleştirmekten bahsediyorum. Gerçek projeler üzerinde ne kadar çok çalışma pratiği yaparsanız, işinizi nasıl daha verimli ve doğru bir şekilde yapacağınızı o kadar iyi anlarsınız.

Bugün konfigürasyon havuzunun uygulama çözümlerini geliştirme/sonlandırma sürecindeki uygulamadan bahsetmek istiyorum. Neden birçok 1C geliştiricisinin depolama yeteneklerini kullanmaktan kaçındığını bilmiyorum. Özellikle, tüm ekip olarak bir konfigürasyonun geliştirilmesi üzerinde çalışanları anlamıyorum. Bir yapılandırma deposu olmadan, zaten (IMHO) kesinlikle hiçbir şey yoktur. Hayır, kesinlikle bir konfigürasyonu tüm geliştiricilere kopyalamak gibi sapkınlıklara girebilirsiniz. Herkes çalışmaya ve üzerine düşeni yapmaya başlar. Geliştirmenin sonunda, geliştiricilerin her biri, yapılandırmalarını son istemciye teslim edilecek olanla senkronize etmelidir.

Bu yaklaşımla, konferansın alaka düzeyini takip etmek oldukça sorunludur. İki veya daha fazla geliştirici, ilgili iki görev üzerinde çalışmaya başlar başlamaz, çalışmalarının sonuçlarını birleştirirken cehennem başlar. Bir şeyin üzerine yazma veya birleştirmeme olasılığı çok yüksektir. Antrenmanım sırasında birkaç kez böyle bir durumla karşılaştım ve bir kez daha doldurulmuş bir yumrudan sonra artık böyle yaşamanın mümkün olmadığına karar verdim.

Yapılandırma deposu nedir

Neyse ki 1C:Enterprise 8 platformuyla tanışmadan önce diğer programlama dillerinde (Delphi, PHP) oldukça iyi geliştirme deneyimim olmuştu. Bu nedenle SVN (Centralized Version Control System) gibi kelimeler benim için bir merak değildi. SVN ile hiç karşılaşmamış olanlar için Wikipedia'daki ilgili makaleyi okumanızı tavsiye ederim - http://en.wikipedia.org/wiki/Subversion . İnanın bana, bu harika ve yazılım geliştirme sürecini büyük ölçüde basitleştiriyor.

Şimdi depomuza geri dönelim. Yapılandırma depolaması, 1C:Enterprise platformunun, uygulamalı bir çözümün grup geliştirmesini organize etmeye izin veren bir aracıdır. Yapılandırma havuzu (bundan sonra HC olarak anılacaktır), geliştiricilere, oluşturulan çözüm için bir sürüm kontrol sistemi ve geliştiriciler tarafından yapılan değişiklikleri kontrol etmek için esnek seçenekler sağlar.

Hangi durumlarda HK kullanabilirsiniz?

Belirli örnekleri sıralamadan önce, hemen biraz özetlemek istiyorum. Tabii ki, HC en çok takım geliştirme sırasında faydalı olacaktır. Ancak, hiçbir şey onu tamamen kendiniz için kullanmanızı engellemez. Neredeyse beş yıldır 1C:Enterprise platformunda geliştirme yapıyorum ve yıllar boyunca, HC kullanımının beni kelimenin tam anlamıyla herhangi bir geliştiricinin kabusundan - önceden yazılmış kodu yeniden yazmaktan - kurtardığı öngörülemeyen durumlarla tekrar tekrar uğraşmak zorunda kaldım. Şimdi projelerimin her biri için yapılandırma havuzunun hizmetlerini kullanmaya çalışıyorum. Neden? Niye? Ve en azından burada:

1. Depolama tarihi. Bu belki de benim için en önemli özelliklerden biri. HK kullanan bir çözümün geliştirilmesi sırasında, yapılandırma değişikliklerinin geçmişi otomatik olarak oluşturulacaktır. Örneğin, bir çalışma haftasında yapılandırma birkaç kez güncellendi. Tüm bu değişiklikler dikkatli bir şekilde kayıt altına alınmakta ve tarihçe versiyonları ile güncellenmektedir. Dilerseniz (veya umutsuz bir durum ortaya çıkarsa), her zaman sürüm listesine bakabilir ve gerekirse geri alabilirsiniz. Örneğin, Pazartesi günü yapılandırmada doğru değişiklikler yapıldı ve Salı günü yeni bir geliştirici önemli ölçüde batırdı ve yükseltmelerini yayınladı. Sonuç, hatalı kod içeren bir yapılandırmadır.

Elbette, genç bir programcıya bir şapka verebilir ve ardından manuel olarak geri yüklemeyi deneyebilirsiniz, ancak birkaç düğmeye basıp geri yüklemek daha iyidir. önceki versiyon conf veya talihsiz geliştirici tarafından yapılan değişiklikleri geri alın.

2. Raporlama. Raporu istediğiniz zaman kaydırabilir ve kimin ve ne zaman (ve hangi yapılandırma nesnelerinin) değişiklik yaptığını görebilirsiniz. Bu, meslektaşlarınız omuz silkip şunu kanıtlamaya çalıştıklarında işe yarayabilir: “Nasalnika, bu biz değiliz! Sadece kırıldı!”

3. Uzaktan geliştirme. HC olmazsa olmaz ise uygulama çözümü coğrafi olarak uzak programcılar tarafından geliştirildi. Açıklanması gerektiğini düşünmüyorum.

4. Acil durumların en aza indirilmesi. Geliştiricilerde vidalar kırıldığında birkaç kez (“gençliğim” nedeniyle ve bu tuzağa kendim düşmeyi başardım) tanık oldum. tabii ki her şey son değişiklikler aynı vidalar üzerindeydiler ve geri dönülmez bir şekilde unutulmaya yüz tuttular. "Peki ya yedekler?" - diyorsun. Mümkün değil! Birçok geliştirici bununla uğraşmaktan hoşlanmaz. Hayır, yalnızca aşırı uçtaki insanlar hiç yedekleme yapmaz, ancak benim uygulamamda günde birkaç kez yedekleme yapan çok az geliştiriciyle tanıştım. HC bu sorunu zarif bir şekilde çözer. Aslında, geliştiricinin sadece bir düğmeye basması gerekiyor ve tüm geliştirmeleri anında depoya aktarılacak.

5. Erişim kontrolü. Neyse fazla açıklamaya gerek yok. HK, geliştiriciler için erişim kontrolünü yapılandırmanıza olanak tanır.

Depolar farklıdır.

Başlangıçta, HK yalnızca paylaşılan bir kaynak aracılığıyla çalıştı (8 sürümünde. Çok uygun değildi, çünkü depolamaya dışarıdan (örneğin, İnternet üzerinden) erişimi düzenlemek istiyorsanız, sorunlar vardı. Sürümden başlayarak. 8.1.11, ağ depolarını dağıtmak mümkün hale geldi.Onlarla hem tcp / ip protokolü üzerinden hem de http üzerinden çalışabilirsiniz.İkincisi, İnternet üzerinden depoya erişimi düzenlerken çok faydalı olacaktır.

Şekil 1. Depolama aygıtı şeması

HC'yi dağıtmaya çalışmak

Diyelim ki HK kullanma fikriyle ilgileniyorsunuz ve projeniz için dağıtmayı denemeye karar veriyorsunuz. Depolamanın paylaşılan bir ağ kaynağı üzerinden ve ayrıca tcp/ip protokolünü kullanan bir ağ üzerinden çalışabileceğini zaten biliyorsunuz. Bu notta, bir paylaşım aracılığıyla depolamayı dağıtmaya bakacağım ve bir dahaki sefere ağ seçeneğine bakacağız.

Bu nedenle, yapmanız gereken ilk şey, projenizin temelini hazırlamaktır. Her yerde bulunabilir. Şu anda canlı projeniz için HC'yi dağıtmaya karar verirseniz, bunu yapmak için çok tembel olmayın. destek olmak. Her şey olabilir ve bir kez daha güvende olmak daha iyidir.

Bilgisayarınızda oluşturun paylaşılan klasör(veya hemen sunucuda). Herkese açık hale getirin ve onunla çalışabilecek kullanıcıları tanımlayın. Kullanıcılar derken, geliştirici arkadaşlarınızı kastediyorum.

Bir sonraki adım, veritabanınızı “Konfigüratör” modunda açmak ve “Yapılandırma” -> “Yapılandırma deposu” -> “Depolama oluştur” menüsünü takip etmektir (bkz. Şekil 2).

Şekil 2. Bir konfigürasyon deposu oluşturma

“Depolama oluştur” butonuna tıkladıktan hemen sonra karşınıza Şekil 3'teki gibi bir pencere gelmelidir. İçinde önceden oluşturulmuş bir paylaşımlı klasörü seçmeniz veya uzak bir depolamanın adresini girmeniz gerekir. Paylaşıma dayalı bir havuz oluşturmaya karar verdiğimiz için, bu pencere tam olarak yolu bir klasör olarak gösterecektir.

Şekil 3. HC'nin yerini seçme

Klasörü belirttiğinizde - "İleri" düğmesine tıklayın. Gözünüzü kırpmadan önce, depolama oluşturma sihirbazı, bir yönetici oluşturmanız için bir pencere görüntüler. hesap(Şekil 4). Varsayılan olarak, ad olarak “Yönetici” kullanmanız istenir. Hiçbir şeyin onu değiştirmenizi engellemediği açıktır. Genel olarak, istenen değerleri girin ve “Tamam” ı tıklayın.

Şekil 4. Yönetici hesabı oluşturma

Burada 1C'niz birkaç saniye düşünmeli ve ardından oluşturulan depolamaya bağlanmayı teklif etmelidir. "Evet" cevabını verin. Tebrikler, ilk yapılandırma mağazanızı oluşturdunuz.

"Yapılandırma" penceresine dikkat edin. Kökün kendisinden başlayarak (konfigürasyonun adının yazıldığı yer burasıdır), sağ tarafta küçük kilitler belirdi (bkz. Şekil 5). Bu kilit, nesnenin şu anda yapılandırma deposunda olduğu ve üzerinde değişiklik yapamayacağınız anlamına gelir. Herhangi bir yapılandırma nesnesiyle çalışmanız gerekiyorsa, önce onu yakalamanız gerekir. Çok yakında sitede görünecek olan bir sonraki notta bu ve depolama ile çalışma ile ilgili diğer birçok işlemi nasıl yapacağınızı anlatacağım.

1s sürüm 7.7'de, konfigürasyonun ortak geliştirilmesi veya değiştirilmesi gerçek bir eziyetti. İki kişi ile bile aynı konfigürasyonu sürdürmek için, mevcut veritabanının iki kopyasını yapmak gerekiyordu, ardından değişiklikler yapıldıktan sonra, değişiklikleri bir kopyanın konfigürasyonundan diğerinin konfigürasyonuna manuel olarak aktarmak. Ancak o zaman desteklenen ana konfigürasyon güncellenebilir! Durum, alt sistemlerin yokluğu ile ağırlaştı.

Ortak geliştirme için 1c'nin sekizinci versiyonunda, yapılandırma deposu. Depolama şu şekilde yapılır:

• Depo oluştur

Menüde "Yapılandırma"->"Yapılandırma deposu"->"Depolama oluştur..." öğesini seçin

Depolama dizinine giden yolu belirtin. (Dizin tüm geliştiricilere açık olmalıdır!)

Depo oluşturulduktan sonra, geliştiriciler için kullanıcılar oluşturmak için "Yapılandırma"->"Yapılandırma deposu"->"Yönetim" menü öğesine gidin.

Ve kullanıcılar oluşturun

• Geliştirici Yapılandırmalarını Yapılandırma Deposuna Bağlama

Seç "Konfigürasyon"->"Yapılandırma deposu"->"Depolamaya bağlan..." menü öğesi

Ana veritabanının aynı kopyalarına sahip olduğumuz için, cesurca "Evet" düğmesini tıklayın ve depoya giden yolu, kullanıcı adını ve şifreyi belirtin

Konfigürasyonun depolama ile karşılaştırılmasını bekliyoruz.

Her şey yolunda giderse, nesne ağacındaki yapılandırma nesnelerinin sağında bir kilit simgesi görünmelidir.

• Yapılandırma deposuyla çalışma

Varsayılan olarak, tüm yapılandırma nesnelerinin bir "kilit" simgesi vardır. Konfigürasyon nesnesini değiştirmek için onu yakalamanız, yani onu seçmeniz gerekir. bağlam menüsü nesne öğesi "Depolama için yakala"

yakalama ayarlarını belirtin

Yapılandırma ağacında nesne için bir simge belirecektir.

Nesne başka bir geliştirici tarafından yakalanırsa, yapılandırma ağacındaki nesne şöyle görünür

Sonrasında istenen değişiklikler yapılmışsa, yapılan değişikliklerle nesne tekrar depoya yerleştirilmelidir. Yapılandırma nesnesinin bağlam menüsünde "Depoya yerleştir..." öğesini seçin.

• Yapılan değişiklikleri geri almak ve nesneyi yakalama işleminden serbest bırakmak istiyorsanız, öğesini seçin. nesnenin bağlam menüsünde "Yakalamayı geri al" öğesi

• Bir nesneyi depodan geri yüklemeniz gerekiyorsa, nesnenin bağlam menüsünde "Depodan al..." öğesini seçin. Bu durumda, nesne yakalanırken yapılan değişiklikler kaybolur.

• Ayrıca sürüm geçmişini görüntüleyebilir ve yakalanan ve değiştirilen nesneyi depodaki nesneyle karşılaştırabilirsiniz.

• Kopyalardaki çalışma tamamlandıktan (veya bazı ara aşamalar tamamlandıktan sonra), ana üssün konfigürasyonunu güncelleyebilirsiniz. Bunu yapmak için, "Konfigürasyon"->"Konfigürasyon deposu"->"Konfigürasyonu güncelle menüsündeki öğeyi seçin. depolamadan" veya "Yapılandırma"->"Yapılandırma deposu"->"Yapılandırmayı depolama ile karşılaştırın/birleştirin".

İkinci durumda, konfigürasyonun daha "yumuşak" bir güncellemesi gerçekleşecek, yani ilk konfigürasyon ve depolama nesneleri arasındaki farklar hakkında bir rapor görüntülemek mümkün olacak.

Mutlu gelişme!

Şirket 1C birçok üretir yazılım ürünleri ve iç yapılarını sürekli olarak geliştirir. Ancak programcıların ve 1C yöneticilerinin yüzleşmek zorunda kaldığı çeşitli hataların sayısı, bu alanda çalışmanın asla durmayacağını gösteriyor. Bu hatalardan bazıları küçük ve nadirdir, ancak her deneyimli uzmanın aşina olduğu "klasik" kusurlar vardır. İkincisi, iyi bilinen "Geçersiz veri depolama formatı" hatasını içerir ve bunu çözebilmek arzu edilir.

Datastore Format Hatasını Çözme

Bu hatayla karşılaşmak için kodda ciddi mantık hataları yapmanıza veya ana modülü kaldırmanıza hiç gerek yok. Genellikle, yapılandırmayı güncelledikten, işlemi açtıktan, gücü kapattıktan veya bilgisayarı yeniden başlattıktan sonra, bu hoş olmayan sürpriz, 1C'yi başlatırken ortaya çıkar. Yeniden başlatma yardımcı olmadıysa panik yapmayın - yaygın bir hata basit çözümler kim yardım edebilir. Bunları karmaşıklık sırasına göre ayıralım:

Yapılandırma başlatıldığı ana ek olarak, açılırken "Geçersiz veri deposu biçimi" hatası da algılanabilir harici işleme. Bu durumda, en önemli şey 1C'yi başlatmamaktır, çünkü başlangıçta sistem TMP dizinindeki geçici dosyaların üzerine yazar. İçinde işlemimizi buluyorsunuz - "v8_ *" adında ve tmp uzantılı bir dosya. Bu tür birçok dosya varsa, hangisinin işlemimiz olduğunu anlamak için uzantıyı epf olarak değiştirin ve 1C üzerinden açmayı deneyin.

1C'yi zaten başlattıysanız ve dosyaların üzerine yazılmışsa, benzer adımları işlemenin başlatıldığı başka bir bilgisayarda gerçekleştirmeyi deneyin. Veya kurtarma yardımcı programlarını kullanın silinen dosyalar sabit sürücüde.