Depolama konfigürasyonu ve veri tabanı konfigürasyonu

Bu noktada, Tasarımcı modundan çıkın ve 1C: Enterprise moduna tekrar giriş yapın. Platform size şu mesajı gösterecektir:

Bunun anlamı, doğrudan Infobase depolama konfigürasyonunu değiştiremeyeceğinizdir (ayrıca “veri tabanı konfigürasyonu” olarak ta bilinir). Bunun yeri Tasarımcı yerel düzenlenen geçici bir kopya oluşturur. Açıkçası yapacağınız değişiklikleri doğrudan veri tabanı konfigürasyonuna uygulayamazsınız. Değişiklik yapıldığında konfigürasyonun yanında özel bir işaret gösterilir. Bunun anlamı değişikliğin henüz veri tabanı konfigürasyonunda uygulanmamış olmasıdır.

Veri tabanı konfigürasyonunu güncellemek için aşağıdaki butona basmalıyız (Veya menüden” Veri tabanı konfigürasyonunu güncelle’ yi seçmeliyiz).

Infobase’i kullanıcı modunda çalıştırma

Veri tabanı konfigürasyonu güncellendikten sonra, Infobase’i kullanıcı modunda çalıştırabilirsiniz. 1C: Enterprise açılış formunda 1C: Enterprise butonuna basabilirsiniz veya bunu direk olarak Tasarımcı modundan yapabilirsiniz:

Bundan sonra, açılan pencerede içinde hiçbir şey içermeyen, boş 1C: Enterprise uygulama ekranı göreceksiniz.

Şimdi, kullanıcı modunu kapatıp Tasarımcı moduna geri gelelim ve bizim uygulamamıza işlevsellik ekleyelim.

Metadata türleri

1C: Enterprise uygulamaları geliştirirken “yapı taşları” kullanılır. Nesneler, veri yapıları, karmaşık işlevler ve görünüm. Bu işlem basit bir ev inşa etmeye benzer. Tuğla, zemin kalıpları, kapı, pencere ve çatı kaplama ve benzeri şeyler kullanılır. Örneğin, farklı renkte birçok tuğla aynı amaç için kullanılabilir – sağlam duvarlar oluştururlar. Bu nedenle işlemler arasında çok benzerlik var. Aynı şey kapılar çinde geçerlidir – bunlar dış ve iç kapılar, ama hepsi de “açık” ve “kapalı” işlemleri desteklemek için kullanılır.

Burada konfigürasyon ağacındaki metadata türlerini görebilirsiniz:

Uygulama geliştirirken kullanabileceğiniz metadata nesneleri yapı taşlarının türleri vardır. Her metadata nesnesinin belli amacı ve bu nedenle belli bir yapısı ve davranış türü vardır. Her özel görev için uygun metadata nesne türü kullanmamız gerekir. Aynı şekilde duvar inşa etmek için tuğla kullanırız, çatı malzemeleri veya zemin kalıbı kullanmayız.

1C: Enterprise bu metadata türleri listesinin biz veya başkası tarafından değiştirilmesine izin vermez. Ev inşa etme örneğine geri dönersek, tuğla veya çatı kaplama malzemeleri yerine muz parçacıkları veya kemik çubuklar kullanılmasına aynı şekilde kimse izin vermez. Bu 1C: Enterprise’yi özel bir geliştirme aracı yapar.

Evraklar

Uygulama geliştirmeye ticari işlemleri tanımlama ve kaydetmek için en önemli sistem kayıt nesnesinden başlamanızı öneririz. Bizim için kullanılacaklar:

• – Onarım için malzeme ve yedek parça satın alma
• – Onarım satış işlemleri

Şimdi malzeme satın alarak başlayalım ve 1C: Enterprise kullanarak bu işlevi uygulamak için nasıl bir yol izleriz görelim.

1C: Enterprise’de kayıt işlemlerinin amacı için özel olarak ayrılmış bir metadata nesne türü vardır. Yani evrak. Aşağıdaki özelliklere sahip nesneler için bu metadata nesne türünü kullanmanız önerilir:

• – Olay başka türden bir iş işlemi yansıtır
• – Bir tarih-zaman damgasına ihtiyaç vardır
• – Benzersiz bir numarası vardır

İşlevimizi uygulamak için bu tür yeni bir metadata nesnesi oluşturmaya ihtiyacımız var.

Metadata nesneleri

Tüm tuğlalar duvar oluşturmak içindir. Ama bizim duvarların birkaç farklı türü olabilir (iç duvar, dış duvar), yani farklı türlerde tuğlalara ihtiyacımız olacak. Aynısı ticari işlemler içinde gereklidir. Tüm işlemlerin ortak noktaları vardır. (Tarih ve işlem süresi, defter tutma amaçlı benzersiz kayıt numarası, aynı davranış kalıpları ve daha fazlası). Aynı zamanda her evrak özel kayıt tutma amaçlı benzersiz bir numaraya sahiptir (fatura, irsaliye ve daha fazlası).

İnşaat için gerekli olan malzemeleri sipariş vermemiz gerek. 1C: Enterprise’de uygulama geliştirilirken her metadata nesnenin kendi temel özellikleri vardır ancak biz ihtiyaçlarımızı karşılamak için özelleştirip değiştirebiliriz.

Yani, Platform içinde kodlanmış metadata türlerini değiştirmek mümkün değil ancak metadata nesnelerinin özelliklerini ihtiyaçlarımıza göre değiştirmek mümkündür.

Metadata nesnesi üst nesnesinden veri yapısını, davranış şeklini ve ara yüz görünümünü otomatik olarak alır.

Şimdi ilk metadata nesnemizi yani evrakımızı oluşturalım ve varsayılan özelliklerde hiçbir değişiklik yapılmadan neler yapar görelim.

“Satın alma irsaliyesi (GoodsReceipt)” oluşturma

Her zaman yeni bir evrak oluşturmak, depoya gelen bir kamyondaki ürünleri depoya aktarmak anlamına gelmektedir. Bu evrak a bir isim belirleyelim: “SatınAlmaİrsaliyesi (GoodsReceipt)”.

Gördüğünüz gibi, 1C: Enterprise kullanıcıların veri girmesi, evrak ekleyip silmesi gibi birçok görünümü ve fonksiyonu otomatik olarak üretti.

Şimdi, belge içerisine istediğimiz verileri tanımlamak gerekiyor. İhtiyacımız olan özniteliklerin listesi:

• – Olayın gerçekleştiği tarih ve zaman
• – Muhasebe amaçları için benzersiz bir numara
• – Depo (malzeme kamyondan nereye boşaltılacaksa)
• – Malzemelerin listesi:
  •      – Malzeme
  •      – Miktar

 Evrakın sistem öznitelikleri

Tüm evraklar aynı amaca yöneliktir – ticari işlemlerin defter kaydını tutmak. Bu nedenle, tüm evraklar önceden tanımlı özniteliklere sahiptir:

• – Olayın gerçekleştiği tarih ve zaman
• – Benzersiz numara

Bunları silmenin ya da eklemenin hiçbir yolu yoktur. (Ama belge numaralarını ayarlayabiliriz). Şimdi diğer özniteliklerini ekleyelim.

Depo özniteliğini ekleyelim

Şimdi, biz konfigürasyon ağacına yeni “Depo” özniteliğini ekleyelim:

Sonra, öznitelik için kullanım amacına göre uygun türü seçelim.

1C: Enterprise’nin varsayılan tip olarak sunduğu “String” çokta iyi bir fikir değil gibi görünüyor.

• – Eğer kullanıcı girişini kontrol edemezsek aynı depodan birkaç depo girilmiş olabilir (“Depo 1”,”1 depo”,”1.Depo”). Sonuç olarak, depo özniteliği için filtre uygulamak mümkün olmayacaktır;
• – Tüm evraklarda aynı depoyu yeniden isimlendirmeye ihtiyacımız varsa – teker teker;
• – Depo ismini yazarak ekstra zaman kaybedilecektir (ihtiyacımız olanı listeden seçmek daha kolay olur);
• – Harcanan aşırı disk alanı yok olacaktır.

Bu soruna çözüm olarak, depoların listesini farklı bir metadata nesnesini kullanarak liste olarak saklamaktır. Şimdi, nasıl çalıştığını görelim.

Açık değerler yerine referansları kullanmak

Bunun yerine GoodsReceipt evrakı dışında depoların listesini saklayıp, bu evrak kaydedilirken o listeden referans ile çağrı yapılabilir:

Şimdi listeden depo seçebiliriz, bu giriş işlemi tam kontrol sağlar ve herhangi bir olası hatayı engeller. Biz ayrıca deponun ismini kolayca yeniden adlandırabiliriz, kullanıcı girişini hızlandırdık ve disk alanını koruduk. (Referans için kullanılan string isim genelde daha kısadır).

Ne yazık ki, bu çözüm bir dezavantaj ile birlikte geliyor: biz veri bütünlüğünün korunmasını da düşünmeliyiz. Şimdi listeden bir tane deponun silinmesi halinde ne olduğunu görelim:

Şimdi, Depo 2 hiçbir yerde yok ve biz bu malların nerede olduğunu bilmiyoruz. Ama burada bazı iyi haberler var: Platform veri bütünlüğünün nasıl korunduğunu bilir.

Depoların listesinin oluşturulması

Depolar için hangi metadata nesne türü kullanmalıyız? Platform içinde bu tür listeler için özel metadata nesne türleri bulunmaktadır. Aşağıda listedeki özelliklere sahip metadata nesneleri için bu metadata türlerini kullanmalıyız:

• – Liste öğeleri herhangi bir sırada olabilir ancak nadiren sıra değiştirilebilir;
• – Her öğe için benzersiz bir kod ve referans vardır.

Şimdi Depo kart listesi oluşturalım ve GoodsReceipt evrakının bu kart listesine başvuru yapmasına izin verelim.

Malzeme listesi

Her kamyon farklı bir malzemeyi depoya getirir, yani her evrak için malzeme listesine ihtiyacımız var. Bunu diğer bir depo metadata nesnesi için yaptığımız gibi yapabiliriz:

Ama “tablo bölümünü” kullanmak daha iyi bir seçenektir. Tablo bölümünü “öznitelik içinde tablo” olarak düşünebiliriz (başka bir şekilde uygulanmış olsa da):

Şimdi nasıl çalıştığını görelim;

Not, tablo bölümünün ait olduğu nesnenin ayrılmaz bir parçası olduğunu unutmayın (bizim için “GoodsReceipt” evrakı). Bunun anlamı, tablo bölümünü bağımsız olarak referanslayamazsınız – bunun yerine bütün bir nesneyi kullanmak zorundayız. Örneğin, “Malzeme” tablo bölümüne daha fazla malzeme eklemek istediğinizde, tüm evrak bellekte var, yeni bir satır ekleyip Infobase’e kaydedin.

Malzeme kart listesini oluşturma ve doldurma

Muhtemelen fark ettiğiniz üzere, “Malzeme” tablo bölümündeki Malzeme özniteliği için string türü seçtik. Açıkçası, biz çalışmak için sürekli olarak aynı malzemeleri kullanıyoruz, yani malzemeleri, depolar için yaptığımız gibi ayrı bir kart listesine kaydetmek daha iyi olurdu. Bizim yeni kart listesinin içeriğini doldurmaya ve bu evrakın tablo bölümü içinden referans yapıp listeden seçmeye ihtiyacımız var.

Kullandığımız malzeme listemize daha yakından göz atalım:

• – Elbow W/ low heel inlet
• – PVC DWV Pipe 3-in x 10-ft
• – Extension cord 3 m
• – R22 Refrigerant, 30 Lb

İlk iki maddenin tesisat ile ilgisi vardır, son iki madde ise buzdolabı ile ilgilidir. Bu liste karışık olması yerine neden gruplar içermesin?

Kart listesi öğelerinin gruplanması

1C: Enterprise kart listelerinin hiyerarşik biçimde gruplandırılmasına izin verir. İki tane hiyerarşik türü vardır:

• – “Gruplar ve öğeler”. Windows’taki klasör ve öğe mantığına benzer. Kart listesi içerisine grup oluşturarak daha sonra grup içine öğe oluşturabilirsiniz. Bu hiyerarşik türü öğeleri gruplara bölmek içindir (bizim uygulamada olduğu gibi – malzemeler farklı amaçlar için ayrılmış).
• – “Öğeler”. Bir öğe altına başka bir öğe oluşturarak bir ağaç görünümü oluşturabilirsiniz. Bu hiyerarşik türü öğeleri küçük öğelere ayırmak içindir (şirket yapısı gibi (bölümler, birimler, çalışma grupları ve benzeri gibi) veya coğrafi nesneler (kıta, ülke, il ve benzeri gibi)).

Bu işlem yapıldıktan sonra kart listesinin görünümüne yeni bir buton eklenir:

Yeni grup oluşturmak için kullanabilirsiniz ve bu alanda öğeleri taşı-bırak yaparak gruplandırabilirsiniz.

Varsayılan depo ayarlama

Biz ne zaman yeni bir irsaliye(evrak) oluşturursak özel bir depoya ihtiyacımız olur. Aynı zamanda, şirket varlıklarının %99’unun depolandığı “Ana” depoyu kullanmamız gerekecek, yani bu depoyu varsayılan olarak seçilen öğe yapmak çok mantıklı.

Bu işlevi uygulamak için formda bazı değişiklikler yapmak gerekiyor.

Evrak formu oluşturma

Fark edebileceğiniz gibi, henüz açıkça bir form oluşturmuş değiliz, ama uygulama tamamen işlevseldir. Platform belirtilen bazı metadata nesneler için formları çalışma anında oluşturur. Bu formlar herhangi bir ölçüde metadata nesnesinin ayarları ve 1C: Enterprise kaynak kodu ile değiştirilebilir.

Varsayılan deponun otomatik seçimini ayarlamak ve farklı yollar keşfetmek için ders boyunca denemeler yapalım.

Öncelikle, GoodsReceipt evrakı için bir form oluşturmak gerekiyor.

Evrak sihirbazını açalım. Öncelikle, aşağıdaki form türlerinden birini seçmek gerekiyor:

• – Evrak formu. Evrakın tüm öznitelikleri tek formda gösterilir. Evrak oluştururken veya düzenlenirken kullanılır.
• – Evrak liste formu. Tüm evraklar liste halinde gösterilir. Tüm evrakları listeleyip evraklardan birini bulmak istediğimizde kullanılır.
• – Evrak seçim formu. Diğer bir liste hali, evraklardan birini bulup seçmek veya başka bir nesneden referans yapıldığında seçim yapmak için kullanılır.
• – Serbest form. Boş form.

Daha fazla özelleştirilmiş form oluşturmak için önceden tanımlanmış şablonlar vardır. (Ama şu an hiç şablon yok).

Belge formunun oluşturulma sürecini gösteren ve form editörünün temelleri hakkında bilgi veren bir video.

Form özelleştirme

Form özelleştirme süreci her zaman kullanım olayları ile ilgilidir. Platform bunları oluşturup kullanıcıya gösterirken uygulama kaynak kodunu erişilebilir yapar. Yani, olay işleyicilerini kaynak kodda kullanabiliriz. Kullanılabilen tüm olaylar özellikler alanında listelenmiştir. Örneğin, formun açılış ve kapanış olayları, kullanıcının görsel olarak tıklayarak yapabileceği olaylar ve daha fazlası. Geliştiricinin doğru olayı seçmesi ve form davranışlarını ayarlamak için kaynak kodunu uygulaması gerekir.

Platform, çalışma anında otomatik olarak işlenmekte olan tüm olayları izler. Örneğin, kullanıcı bir butona bastığında Platform o olaya bağlı işleyiciyi çağırır ve kaynak kodu çalıştırır. Diğer bir deyişle, olay işleyicisi olarak bir işlemi yürütür.

Varsayılan depo sorununu çözmek için, bizim form gösterilemeden önceki olayı yakalamamız gerekiyor ve sonra depo özniteliği için “Ana” depoyu atamalıyız.

Bir işleyici oluşturduğumuzda, Platform bize üç seçenek sunar:

• – Create on client (istemci üzerinde)
• – Create on client and a procedure on sunucu: (hem istemci hem sunucu üzerinde)
  •      – context (koşulsuz)
  •      – With context (koşullu)

İşleyiciyi oluşturmaya başlamadan önce, bu üç seçeneğin ne olduğunu deneyerek anlayalım.

İstemci/sunucu etkileşimi

Her zaman iki bağımsız aktör uygulama mimarisini inşa eder ve çalıştırır:

• – Client (İstemci):
  •      – Kullanıcı ara yüzünde formlar ile çalışır
  •      – Infobase’e erişim sağlamaz (herhangi bir infobase verisini okuyamaz ve düzenleyemez)
  •      – Ama sunucu prosedürleri çağırır,
• – Server (Sunucu):
  •      – Infobase ile çalışır (herhangi bir infobase verisini düzenler ve okur),
  •      – İstemci çağrılarını çalıştırır
  •      – Arkaplan işlemleri çalıştırır.

Bizim depo özniteliğimiz için “CatalogRef. Warehouses” türünü seçtik. Referans – bu GUID (global benzersiz tanımlayıcı), yeni bir nesne oluşturulduğunda Platform tarafından otomatik tanımlanır. Şimdi “Ana” deponun infobaseden değerini almaya ihtiyacımız var. 1C istemcisinin bunu yapabilme imkânı yok, bu yüzden bunu sunucuya sormamız gerekir. Diğer bir deyişle, istemci olay işleyicisinin ihtiyacı olan bir prosedürü sunucu da çağırmalıyız. With veya without context?

“With context” kullanımının anlamı tüm formun kaynak olarak sunucuya gönderilmesi anlamına gelir. Bazen istemcinin sunucuda çağırdığı bazı prosedürler ile formun doldurulması gerekli olabilir. Bu bağlamda sunucu çağrı yapılan formun tamamına erişebilir, yani doğrudan form özniteliklerini okuyor ve yazıyor.

Açıkçası, sunucuya gelen tüm bilgi içerisinde arama yapmak ve istenilen yeri doldurmak için yerel ağda fazla bant genişliği kullanılır, bu yüzden bu çağrıyı kullanmak istemiyoruz. Bizim tek ihtiyacımız olan bir kart listesi öğesi için referans değeri okuma ve kullanıcıya bunu geri dönüş yaparak formda göstermek. Yani içerik olmadan da çağrı yeterince iyi görünüyor.

Bu video, olay işleyicisinin uygulamayı çalıştırma sürecinde nasıl çalıştığını gösteriyor.

İhtiyacımız olan kaynak kod:

Olay işleyicileri hakkında birkaç kelime daha. Unutmayın ki, olay işleyicileri iki bağımsız işlemi içerir:

• – İşleyici prosedürünü uygulamak
• – Belirli bir olay için bu prosedüre katılmak

Bu iki şey arasında farklılıklar vardır. Form’da OnOpen () prosedürünü kullanmak onu olay işleyicisi yapmaz. Sadece Platform tarafından yapılan çağrılara katılır. Örneğin, özellikler panelinden seçilen bir olay işleyicisi.

Bu form modülü için yazılan kaynak kod:

Sunucuda oluşturulan çağrıya katılmadıkça Platform tarafından yürütülmez.

Bunun anlamı, olay işleyicilerinin özel bir ismi olmasına gerek yoktur. Bu sadece bir prosedür ve bizim istediğimiz ismi verebiliriz. Ama bu olay işleyicisinin belirli parametreleri tam sayılı olmalıdır.

Yani bu formun OnOpen prosedürü aşağıdaki isimlerde de olabilir. Çünkü hangi isimde olursa olsun özellikler panelinin OnOpen olay işleyicisinden seçtiğimiz için sadece form açıldığında çalışacaktır. Örneğin;

Nesne tekniklerini kullanarak veri okuma ve yazma

Bu örneğimizde, nesne tekniğini kullanarak kart nesnesini okuyacağız. Bunu kullanarak 1C sunucu belleğinden infobase nesnelerini okumak veya 1C sunucu belleğinden infobase’ye yazmayı yapabiliriz.

1C: Enterprise nesnelerinin yaşam döngüsüne yakından göz atalım:

Bu tekniği kullanarak, her zaman tek bir nesne işleyebilirsiniz. Bunun anlamı toplu veri işlemek için döngü gerekir. Unutmayın ki, bu döngü veri büyüdükçe büyük ölçüde sistem performansını etkileyebilir ve gidiş-dönüş etkisi açısından iyi bir fikir olmayabilir. Yani, biz birden fazla nesne okumak istiyorsak, 1C sorgusu kullanmalıyız (dersin ilerisinde göreceğiz).

Nesne tekniğinin bir başka dikkat çekici özelliği, her zaman bir bütün olarak nesneyi işlemek olmasıdır. Diğer bir deyişle, bize gerekli olan birkaç özniteliği infobase den okuyamayız bunun yerine tüm nesneyi okuyup bellekte tutarız. Bu durumda yalnızca referans vermeye ihtiyacımız var, ama tüm depo kart listesini okumak zorunda kaldık, aslında ihtiyacımız olandan daha çok okuma yaptık ve daha çok bellek ayrılmış oldu.

Peki; Bunu önlemenin herhangi bir yolu var mı?

Sorgu kullanarak veri okuma

Hatırlamanız gereken en önemli şey, nesne tekniğini kullanarak veri yazmanızın tek bir yolu olduğudur. Konu okumak olduğunda ise böyle değil.

1C: Enterprise’de veri okumak için bir yol daha var, oda sorgular. Nesne tekniğinin aksine sadece ihtiyacımız olan verileri ve tek seferde birçok nesneyi okuyabiliriz (döngü kullanmadan).

Öte yandan sorgu ile veri yazamayız. Sorguların olumsuz bir yanı vardır. Bu da sorguları çalıştırmaya başlamak için çok fazla kod yazılmasıdır.

1C: Enterprise’nin sorgular ile nasıl çalıştığını görelim:

Bu kod Sorgu Yapılandırıcısı ile otomatik olarak oluşturulmuştur:

Şimdi, sorguyu çalıştıralım ve ne yaptıklarını görmek için satırları gözden geçirelim.

Değişken tanımlama ve atama

Bu kod satırında “Query” adında bir değişken tanımlar ve “Query” türünde yeni bir nesneye atar.

Sol taraftaki “Query” kelime atamasının ismini bize kolaylık sağlayacak şekilde istediğimiz gibi seçebiliriz. Bu neredeyse herhangi bir şey olabilir: “MyQuery”, “GetMainWarehouseQuery” – biz ne istiyorsak o. Geliştirici rehberi bu konuda şöyle der:

“Değişken ismi sayı, harf, alt çizgi içerebilir ve alt çizgi karakteri ile başlayan string olabilir. Yeni isimler özellikleri farklı olan diğer nesnelerin isimleri ile de aynı olamaz. Değişken, prosedür ve fonksiyon isimleri küçük büyük harfe duyarlı değildir”.

Değişken tanımlama ve atama hakkında bilmeniz gerek birkaç şey daha vardır:

• – “Var” operatörü kullanarak değişkenleri açıkça tanımlayabilirsiniz;
• – Bunu yapmak zo runda değiliz. Değişkenler bir değer atadığınızda Platform tarafından oluşturulur.
• – Bir değişkene değer atamak için her zaman yeniden oluşturulurlar (ve yeni nesne türü olabilir).

Değişkene basit bir veri türü atayabilirsiniz (MyName = “Konstantin”;) ya da “New” operatörü ile karmaşık bir türde nesne oluşturur ve bu değişkene atayabilirsiniz (nesne odaklı programlama kavramına aşina olanlar için: “New” operatörü kullanarak temek sınıf oluşturucusu çalıştırın). Bu satır tam da bunu yapmaktadır. Bu karmaşık türdür (örn. Sınıf). “Query” Platform’da önceden tanımlanmıştır. “New Query” operatörü, bu sınıfın yeni bir nesnesini oluşturur.

1C Sorgu metni

“Query.Text” String özelliğinde sorgu metni içeren bir metindir.

1C: Enterprise sorgu dili sözdizimi temel SQL (Structured Query Language) standart sorgu sözdizimine dayanmaktadır. SQL’in aksine, 1C sorgu dili DML, DDL veya DCL gibi SQL standart alt kümelerini desteklemez. 1C uygulanan tel SQL işlemi “SELECT” ifadesidir. Bu şu sorguları 1C’de kullanamayacağınız anlamına gelir:

• – Infobase verilerini değiştirme (bunu nesne teknikleri kullanarak yapabilirsiniz)
• – Infobase veri yapısını değiştirme (bunu Tasarımcı modunu kullanarak yapabilirsiniz)
• – Kullanıcı erişim haklarımı düzenleme (bunu Tasarımcı modunu kullanarak yapabilirsiniz).

“SELECT” ifadesi ile 1C sorgu dilinde standart SQL özelliklerinin hepsini kullanabilirsiniz: koşul arama, join (katılım), gruplar, sipariş ve daha fazlası. Ek olarak, daha sonra ele alınacak bazı 1C sorgu özellikleri.

Bizim sorgu metnimiz oldukça kısadır: “Ref” ifadesi ile “Depo (Warehouses)” kart listesinde “Description” özniteliğinin “&Description” koşuluna uygun olan kayıt için tüm öznitelikler alındı. “&” sembolü sorgu koşulunu sorgu metni içinde tanımlarken parametrenin önüne eklenir.

Dikkatinizi çekmek istediğim bir konu daha var, sorgu içinde nesne isimleri ve tanımları arasında fark vardır:

 “FROM Catalog.Warehouses” şeklinde Tasarımcı da tanımlı olan nesneyi, “AS Warehouses” tanımlaması ile yeni ismiyle sorgu içinde istediğimiz yerde çağırabiliriz. Bu işleme isim kısaltması da diyebiliriz. “Official” kart listesi adı sadece bir yerde (in “FROM” ifadesi), yeni ismi geri kalan her yerde kullanılır- “SELECT” veya “WHERE” ifadeleri içinde. Farkı vurgulamak için bir soru daha yazıp görelim:

Sorgu parametreleri ayarı

Sorgu koşulu belirtmek için birden fazla yol vardır.

Sabit sorgu koşulu “Main” aşağıdaki gibi kullanılabilir:

Görüldüğü gibi “Main” çift tırnak içindedir. Not, string şeklinde sabit sorgu koşulu yazılırken çift tırnak içinde yazmalısınız.

Parametre kullanımının farklı bir yolu vardır. 1C içinde, sorgu parametresi belirlemek için & sembolü kullanılır. Daha sonra SetParameter metodu kullanılarak sorgu metni parametreleri atanıp, ayarlanabilir:

Not, bu ikinci yöntem kullanıldığında parametrenin sözdizimi kontrolünden geçmeyeceği anlamına gelir. Yani, biz sorguyu şöyle yazabiliriz:

Sorgunun çalıştırılması

Bu satır DBMS içinde sorguyu çalıştırır ancak sorgu sonucu döndürmez. Bu noktada sorgumuzun herhangi bir satırı döndürdüğünü kontrol edebilirsiniz. (Var olmayan verileri okumaya çalışırken sunucu çağrılarının aşırı artmasını önlemek için). Bunun için IsEmpty () metodunu kullanmak gerekir.

Bu 1C sunucu kodu elde edilen verileri erişilebilir yapar, yani bundan sonra şu kodu kullanarak

1C sunucu belleğinde olan sonuç kümesinin bir alt satırını alabiliriz. Bu fonksiyon başarıyla alınan birden fazla satır varsa onları almak için de kullanılır. Eğer fonksiyon TRUE döndürürse bir sonraki kayda erişebilirsiniz demektir. Bir sonraki video da nasıl olduğunu göreceğiz.

Çalışıyor gibi gözüküyor ama bir sorun daha var. Kullanıcı “Main” öğesinin ismini değiştirirse veya bu öğeyi kart listesinden silerse, yazdığımız bu kod çalışmayı durdurur.

Önceden tanımlanmış kart listesi öğeleri

Kullanıcı tarafından (kasten veya yanlışlıkla) infobase verisi değiştirildiğinde bizim yazdığımız kod sorun çıkartıyordu. Diğer bir deyişle, biz kaynak kod içine veri hakkında bilgi dâhil ettik, kötü bir şekilde. Eğer kodda bir şey (“koşul”) kullanmak istiyorsak, bu uygulama içinde açıkça beyan edilmelidir.

Akla ilk gelen çözüm erişim kısıtlaması uygulayarak kaynak kodumuzun hata vermemesi için veri değiştirilmesini engellemek olabilir – karmaşık ama teorik olarak uygulanabilir. Ama biz uygulamayı kullanıcılara dağıttığımızda ne olur? Uygulama içinde veri yok, sadece yapılandırma içeriyor, bu durumda yine bizim kodumuz işe yaramaz olur.

En iyi karar için “Önceden tanımlanmış veri” diyebiliriz.

Her kart listesi herhangi bir sayıda ikili yapısı olan önceden tanımlı öğe içerebilir: diğer yandan, bunlar uygulamanın bir parçasıdır, yani onları kod içerisinde kullanabileceğimize emin olabiliriz. Öte yandan, diğer tüm (kullanıcı tanımlı) öğelerde birlikte kart listesinin ara yüzünde gösterileceklerdir.

1C: Enterprise modunda infobase çalıştırıldığında Platform tarafından otomatik olarak oluşturulan öğeleri önceden tanımlı öğeler olarak düşünebiliriz.

“Ana (Main)” deposunu önceden tanımlı yapalım ve kodda nasıl kullanıldığını görelim.

Sonuç olarak kaynak kod:

Sunucu çağrıları

Şimdi, bir ayrıntıya dikkatinizi çekmek istiyorum. Burada 1C: Enterprise penceresinin sol alt kısmında gerçek zamanlı olarak istemci/sunucu çağrılarının sayısı gösterilmektedir.

Bir kullanıcı “Oluştur” butonuna bastığında gerçekleştirilen sunucu çağrıları sayısına göz atalım. İlk çalıştırmada bu sayı büyük olur, ama şimdiye kadarki istemci önbelleği boş olduğu için çağrılar sayılmaz. Tüm ardışık çalıştırmalarda 2 sunucu çağrılarını her zaman verir.

Tamam, ama bu konu bizi neden rahatsız etsin ki?

Bu konu için istemci ve sunucu arasında binlerce kilometre uzunlukta bölünmüş kablo olabilir, kablosuz ağlar yüzlerce metre, çok sayıda bağlantı noktası, yönlendirici ve diğer ağ cihazları. Bu 0.5 saniye veya bunların hepsi arasında seyahat etmek için daha uzun sürebilir. Eğer gerçek dünyada bir uygulama geliştirmek istiyorsak, her sunucu çağrısının 0,5 saniye ye mal olacak diye düşünebiliriz. Formlar her zaman açılmadan önce 2 sunucu çağrısı için kullanıcının 1 saniye beklemesi gerekmektedir.

Bu yüzden, aşırı sunucu çağrıları büyük ölçüde sistem performansını ve kullanıcı memnuniyetini olumsuz etkileyebilir. Bu nedenle, başparmak kuralını kullanmalıyız: bir kullanıcı işlemi – bir sunucu çağrısı.

Şimdi bu iki çağrının nereden meydana geldiğini görelim.

Yani ilk çağrı kullanıcı “Oluştur” butonuna bastığında oluşur ve daha sonra ikincisi oluşur – istemci de “OnOpen” olay işleyicisi ve sunucu da “OnOpenAtServer” sunucu prosedürü çalıştırılır.

Biz bu ek çağrıdan nasıl kurtulacağız?

Eğer yukarıdaki resme bakarsanız, form sunucu tarafında oluşur. Sunucu tarafında form oluşturma sırasında “Main” değeri ile depo özniteliğini doldurmalıyız. Görelim:

Başlangıç alan değeri

Bugün için bir şey daha düşünelim. Bu görev çözümü oldukça sık kullanılacak gibi gözüküyor. Kodlama olmadan çözmek için Platform üzerinde bazı ayar kısımları var mıdır?

Evet, öyle:

Bazı metadata nesnelerinin öznitelikleri için Tasarımcı modunda varsayılan değer atamaya izin verilir, yani burada bu işlevselliği uygulamak için kaynak kod yazmaya gerek yoktur.

Şimdi, yazdığımız tüm kaynak kodu silelim ve “Fill value” özelliğini kullanarak varsayılan değer ataması yapalım.