Previous Function (Reporting Services)
Detay satırında, bir önceki satırdaki değeri okumak için kullanılıyor.
Örnek
Bir önceki değerle karşılaştırıp, bulunulan satırdaki görsel öğeler ile oynananabilir. (Bir önceki satırla aynı değere sakip olan bir alanı “Bold” yapmak gibi)
Expression for FontWeight
=iif(Fields!NUMARA.Value=Previous(Fields!NUMARA.Value),"Bold","Normal")
Buradan ayrıntılı bilgi alınabilir.
http://msdn.microsoft.com/en-us/library/ms156372%28v=sql.100%29.aspx
Bir işlemin (transaction'in) otomatik olarak çalıştırılması.
TXN’i zamanlanmış göreve ekletirken göz önünde bulundurulması gereken bir konu ; Request Message’daki alanlara hangi değerler atandıysa o değerler kullanılır. Örneğin, request mesaja her seferinde farklı bir lokasyon id geçilemez.
Hangi periyotta çalıştırılması isteniyorsa, devreye alım ekibine bildirilir.
Örnek-1
<Transaction Name=" KpkKontTarihceHizmetTutarGuncelle" Group="HS" Module="Genel " UserId="0">
<Schedule Frequency="Daily" StartHour="21" StartMinute="15" StartSecond="00"/>
</Transaction>
Örnek-2
<Transaction Name=" UretilemeyenDosyaLogTekrarGonder" Group="Loglama" Module="EntOzel" UserId="0">
<Schedule Frequency="Hourly" HourInterval="2"/>
</Transaction>
UserId’inin etkilediği bir durum yoktur. Zamanlanmış görevi çalıştıran kullanıcı 850’dir. Normal olan otomatik çalışacak TXN’in sıfırdan yazılmasıdır. Eğer hazırladığınız işlem sadece bu iş için yazılmadı ise, hem arayüzden hem otomatik olarak çalıştırılacak ise, TXN içine aşağıdaki gibi bir kontrol eklenerek tek TXN üzerinden işlemler yapılabilir. Burada dikkat edilmesi gereken husus, herhangi bir entegrasyonun bu TXN i çağırır ise onun da kullanıcı id’si 850 olduğu için aynı kod bloğuna girecek olmasıdır.
public void Execute(KpkKontTarihceHizmetTutarGuncelleRequest request, KpkKontTarihceHizmetTutarGuncelleResponse response)
{
bool scheduledJobMode = (request.KullaniciId == EntegrasyonConstants.EntUserId);
if (scheduledJobMode)
{
Artık burada ne isteniyor ise...
Objeleri üzerinde “update” ve “delete” işlemlerini , objeyi “id’si ile new’lemeden” dolayısıyla, Veri tabanına bir “select” atmaya gerek duymadan yapmanın bir yolu var.
Silme işleminde hiç bir sıkıntı yok. Hatta tüm silmeleri böyle yapmamız gerekiyor diyebilirim. Fakat güncelleme’de “re-factor” yaparken dikkat edilecek bir husus var. Eğer new’lenen objede, güncellediğiniz alanlar dışında başka bir alandan bilgi alıyorsanız o alan boş gelecektir, ama güncellenecek alan belli, değer belli ise, yapıştırın gitsin. Aşağıda örneği var.
Kolay gelsin.
Bildiğimiz, sevdiğimiz kullandığımız yöntem L
KpkKontTarihceHizmetEntity guncellenecekKpkKontTarihceHizmetEntity = new KpkKontTarihceHizmetEntity(55); //burda VT’te select attı. Objeji doldurdu.
transactionHelper.AddElementToTransaction(guncellenecekKpkKontTarihceHizmetEntity);
guncellenecekKpkKontTarihceHizmetEntity.tutar = 500;
guncellenecekKpkKontTarihceHizmetEntity.Save();
Güncelleyeceğimiz objenin ID’sini biliyorsak kullanacağımız, cillop gibi yöntem J
KpkKontTarihceHizmetEntity guncellenecekKpkKontTarihceHizmetEntity = new KpkKontTarihceHizmetEntity();
guncellenecekKpkKontTarihceHizmetEntity.Fields["Id"].ForcedCurrentValueWrite(55); //(llblgen’de generate işleminde readonly=false ayarlanırsa, id’te direkt atama yapılabilir)
guncellenecekKpkKontTarihceHizmetEntity.IsNew = false;
transactionHelper.AddElementToTransaction(guncellenecekKpkKontTarihceHizmetEntity);
guncellenecekKpkKontTarihceHizmetEntity.tutar = 500;
guncellenecekKpkKontTarihceHizmetEntity.Save();
Ayrıntılı Açıklama
Modifying an entity's data is just as simple and can be done in multiple ways:
Option 1 is likely the most used one, since an entity might already be in memory. As with all the suggested options, the Save() method will see that the entity isn't new, and will therefore use an UPDATE query to alter the entity's data in the persistent storage. An UPDATE query will only update the changed fields in an entity that is saved, which results in efficient queries. If no fields are changed, no update is performed. A field which is set to the same value (according to Equals()) is not marked as 'changed' (i.e. the field's IsChanged flag is not set).
If you've loaded an entity from the database into memory and you've changed one or more of its primary key fields, these fields will be updated in the database as well (except sequenced/identity columns). Changing PK fields is not recommended and changed PK fields are not propagated to related entities fetched in memory. You also can't save changed PK fields in recursive saves.
An example for code using the first method:
// [C#]
CustomerEntity customer = new CustomerEntity("CHOPS"); customer.Phone = "(605)555-4321";
customer.Save();
This will first load the Customer entity "CHOPS" into memory, alter one field, Phone, and then save that single field back into the persistent storage. Because the loading of "CHOPS" already set the primary key, we can just alter a field and call Save(). The Update query will solely set the table field related to the entity field "Phone".
Reading an entity into memory first can be somewhat inefficient, since all we need to do is an update of an entity row in the database.
Option 2 is more efficient in that it just starts an update, without first reading the data from the database. The following code performs the same update as the previous example code illustrating option 1. Even though the PK field is changed, it is not updated, because it is not previously fetched from the database.
// [C#]
CustomerEntity customer = new CustomerEntity();
customer.CustomerID="CHOPS";
customer.IsNew=false;
customer.Phone = "(605)555-4321";
customer.Save();
We have to set the primary key field, so the Update method will only update a single entity, the "CHOPS" entity. Next, we have to mark the new, empty entity object as not being new, so Save() will call the Update method, instead of the Insert method. This is done by setting the flag IsNew to false. Next is the altering of a field, in this case "Phone", and the call of Save(). This will not load the entity back in memory, but because Save() is called, it will be marked out of sync, and the next time you'll access a property of this entity's object, it will be refetched from the persistent storage. Doing updates this way can be very efficient and you can use very complex update constructs when you apply an Expression to the field(s) to update. See for more information about Expression objects for fields Field expressions and aggregates.
|
|
|
