Yazar arşivleri: Ahmet Kaymaz

JQUERY – ASP.NET POST işleminde Türkçe Karakter Sorunu

JQuery aracılığıyla bir formu ASP.NET sayfasına doğrudan POST veya GET ile gönderebilmek için Form Serialize işlemi gerçekleştirilir. Bu amaçla .serialize() veya .serializeArray() yordamları kullanılır.
Özellikle Internet Explorer ortamında bir formu serialize edip ASP.NET sayfasında okumaya çalıştığımızda Türkçe Karakter sorunu yaşanmaktadır. Örneğin “öçşğüİ” değeri öçÅ?Ä?Ã¼Ä şeklinde görünmektedir. Bu karakterlerin UTF-8 olarak gönderilmesi için aşağıdaki örnekte gösterildiği gibi “application/x-www-form-urlencoded; charset=utf-8¨ şeklinde content teype belirmek gerekiyor.

var formValue=$("#aspnetForm").serializeNoViewState();

$.ajax({
	type: "POST",
	url: "OrnekSayfa.aspx?Prm=1",
	data: formValue,

	beforeSend: function (xhr) {
	    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded; charset=utf-8");
	},

	contentType: "application/x-www-form-urlencoded; charset=utf-8",
	dataType: "json", 

	success: function (msg, status) {
		alert(msg);
	},
	error: function (xhr, msg, e) {
	    alert("Hata Oluştu!\n" + xhr.responseText +"\n"+msg );
	},

	complete: function() {
		alert('İstek başarıyla gönderildi.');
	}
});

ASP.NET requestValidationMode ayarı

ASP.NET sayfasına POST işlemi yaptığımızda post edilen metin içerisinde “<>” gibi web safyaları için tehlike oluşturabilecek değerler gönderildiği zaman ASP.NET WP, “A potentially dangerous Request.Form value was detected from the client” hatasını fırlatır. Bu hatayı engellemek yani kullanıcının bu tür değerleri girmesine izin vermek için ASP.NET sayfasının tanımlama satırına validateRequest=”false” ibaresi yazılır. Aynı şekilde uygulamadaki tüm sayfalar için bu ayarın geçerli olması için Web.Config dosyasına aşağıdaki gibi ekleme yapılabilir. Cross-site scripting (XSS) attack riskini engellemek için ASP.NET tüm sürümlerinde request validation özelliği varsayılan olarak aktifdir. ASP.NET’in önceki sürümlerinde bu doğrulama işlemi sadece ASPX sayfaları için yapılmaktaydı. 4.0 sürümüyle birlikte doğrulama işlemi doğrudan BeginRequest aşamasında devreye alınacak şekilde düzenlendi. Böylece uygulamaya gelen tüm istekler için yani sadece ASPX sayfaları değil, Web Servisi çağırma, HTTP handler çalıştırma gibi tüm ASP.NET kaynaklarına istek gönderildiği zaman doğrulama işlemi devreye alınmış oldu.
Bazı durumlarda .NET Framework 4.0 altında eski sürüm ugyulamalarını çalıştırma durumumuz olabilir. Bu durumda hangi sürüm algoritmasının kullanacağını belirtmek için requestValidationMode niteliği kullanılır.


SQL Server Replication – Şema Değişikliği

Kurulu olan bir replikasyona yeni nesne ekleme, mevcut nesne silme gibi işlemler bir gereksinim olduğu gibi bazı durumlarda tablodaki kolonların veri tipi değişimi, kolon adı değişimi gibi ihtiyaçlar da doğabiliyor. Daha önce yazdığımız SQL Server Replication – Yeni Tablo Ekleme makalesinde replikasyona yeni bir tablo nesnesinin nasıl ekleneceğini örneklendirmiştik. Bu yazıda da bir tablodaki kolonu replikasyona eklemek, replikasyonda çıkarmak ve şemasını değiştirdiğimizde replikasyonun nasıl etkileneceğini göreceğiz. Okumaya devam et

Replikasyonda MaxCmdsInTran Parametresi

SQL Server 2000 üzerinde kurduğumuz replikasyon aracılığıyla 50 tane şubeyi merkeze kolayca ve hızlıca taşıyabildik. Ancak SQL Server 2005 kullanan şubelerimiz nedenini henüz çözemediğim bir yavaşlıktan dolayı şube tarafında çok uzun sayıdaki transactionlar merkeze geç aktarılıyor. Farklı alternatifler denememe rağmen başarılı olamadık. Şube tarafındaki bulk işlemlerden dolayı bir transaction içerisinde çok sayıda command eklenmektedir. Buradaki sıkıntı kuyrukta bekleyen çok sayıdan komut satırının herhangi bir bağlantı kesilmesinde rollback edilecek olması ve her defasında yeniden baştan itibaren aboneye gönderilmesidir. Örneğin bir transaction setinde 100bin komut olduğunu düşünelim. Bunları adım adım aboneye gönderirken 90bininci satırda herhangi bir bağlantı kesilmeside abone üzerinde tüm işlemler rollback edilecek ve bir sonraki bağlantıda 100bin satır yeniden gönderilecektir. Bu işlemi hızlandırmak için bir çözüm bulamadım. Bunun yerine bir transaction içerisine daha az komut eklenecek şekilde bir düzenleme yapmak en azından rollback sürecinde daha az satır için gerigönderme işlemi yapmış olacaktır.
Bu işlem için SQL Server 2000 SP1 ile gelen MaxCmdsInTran parametresi kullanılmaktadır. Bu parametre için MSDN’de aşağıdaki tanım yazılmıştır.
-MaxCmdsInTran number_of_commands
Requires Service Pack 1 or later. MaxCmdsInTran specifies the maximum number of statements grouped into a transaction as the Log Reader writes commands to the distribution database. Using this parameter allows the Log Reader Agent and Distribution Agent to divide large transactions (consisting of many commands) at the Publisher into several smaller transactions when applied at the Subscriber. Specifying this parameter can reduce contention at the Distributor and reduce latency between the Publisher and Subscriber. Because the original transaction is applied in smaller units, the Subscriber can access rows of a large logical Publisher transaction prior to the end of the original transaction, breaking strict transactional atomicity. The default is 0, which preserves the transaction boundaries of the Publisher.

Bu parametre Log Reader servisi için kullanılmaktadır. Görsel olarak set edilecek bir alan bulunmamaktadır. Bunun için SQL Server Agent altında çalışan Log Reader servisine ait Job’ın özellikleri kullanılır. Log Reader job’ının Properties menüsü tıklanarak Agent’i çalıştıran adıma “-MaxCmdsInTrans 1000¨ şeklinde değer girilebilir. Bu durumda Log Reader bulk işlemlerinde her transaction bloğunda 1000 komut olacak şeklinde ayarlama yapar.

Aynı Schedule’in Ayrı Job’lar Tarafından Kullanılması

Bu yazıda SQL Server 2005 ile birlikte gelen ve özellikle birçok Job tanımlanmış sistemlerde kolaylık sağlayacak bir özelliği paylaşmak istiyorum. Tanımlanmış olan bir schedule’in birden fazla Job tarafından paylaşılabiliyor olması. Özellikle birçok Job’ın olduğu durumlarda bazılarını aynı anda başlatma ihtiyacımız olabilir. Bunlar için tek bir zaman tanımlayıp gerektiği durumda zaman ayarlarını güncelleme imkanımız olabilmektedir. Okumaya devam et

SQL Server Önceki Satırların Toplamı

Özellikle bazı raporlarda veri satırlarının yanına kendinden önceki satılardaki bir alanın toplamını yazma ihtiyacı duyabiliyoruz. Aşağıdaki gibi Satis isimli bir tablo olduğunu düşünelim.

Bu tabloda her dönemin karşısında o döneme ait ciro bulunmaktadır. Bu tablodaki verilere dayalı olarak aşağıdaki gibi bir sonuç elde etmek istiyoruz.

Okumaya devam et

Showplan SET ifadeleri ile Execution Plan gösterimi

SQL Server’deki bir sorgunun hangi yöntemle çalıştırılacağını SQL Server’in ürettiği Execution Plan’a bakarak anlayabiliriz. SQL Server’in sunduğu gösterim planı ifadelerini (Showplan SET statements) kullanarak o anki Execution Plan hakkında daha geniş bilgi alabiliriz. Sorguya ait execution plan’ı görmek için temel olarak aşağıdaki deyimler kullanılır.
SET SHOWPLAN_ALL ON
SET SHOWPLAN_TEXT ON
SET SHOWPLAN_XML ON
SET STATISTICS XML ON
SET STATISTICS PROFILE ON
SET STATISTICS IO ON
SET STATISTICS TIME ON Okumaya devam et

SQL SERVER 2008 – Surface Area Configuration

SQL Server 2005 ile birlikte “Surface Area Configuration” isimli ayrı bir programcık kurulur. Bu araç aracılığıyla SQL Server ve Analysis Services, SQL Server Agent, Full-Text Search, Integration Services, SQL Server Browser gibi SQL Server üzerinde çalışan alt servislerin yönetimi sağlanır. Ayrıca Ad Hod Remote Queries, CLR Integration, DAC, Database Mail, xp_cmdshell gibi veritabanı tarafında SQL dünyası dışındaki özelliklerin aktif veya pasifleştirilmesi sağlanır. Bu araca Start » Programs » Microsoft SQL Server 2005 altındaki Configuration Tools bölümden ulaşılır.

SQL Server 2008’te bu araç ayrı bir program olarak kurulmayıp Policy Based Management kapsamında sunulmaktadır. Policy Based Management, SQL Server üzerinde oluşturulmuş olan kuralların yönetildiği alandır. Policy Based Management altında yeni policy (kural) oluşturulabilir veya mevcut policy’ler yönetilebilir. PBM altındaki Facet bölümü policy oluştururken kullanabileceğimiz temel özellikleri içermektedir. “Facet” kavramını SQL Server üzerinde veritabanı yöneticisi tarafında yönetebilecek özellikler olarak tanımlayabiliriz.

Konuya geri dönecek olursak “Surface Area Configuration” yönetimini SQL Server 2008’de Facets bölümü altında yapabiliyoruz.

SQL Server Replication – Subscriber Expire & Deactivate Olması

SQL Server Data Replication içinde tanımlı abonelikler (subscription) belirlenmiş olan transaction saklama süresi (retention period) içinde senkronize edilmezse otomatik olarak pasif moda çekilebilir veya expire edilebilir. Transactional Replication yönteminde maximum distribution retention period (sp_adddistributiondb prosedürü için @max_distretention parametresi) ve publication retention period (sp_addpublication prosedürü için @retention parametresi) olmak üzere iki temel parametre kullanılır. Okumaya devam et

SQL Server Replication – Kayıt atlama

SQL Server Replication nasıl ayarlanır ?

SQL Server replication uygulaması doğası gereği replikasyona dahil edilmiş nesneler üzerinde yapılan tüm değişiklikleri SQL ifadeleri olarak Log Reader Agent aracılığıyla Distribution veritabanına aktarır. Distribution Agent de bu komutları subscriber’lara gönderir. Yanlışlıkla yaptığımız bir Bulk Insert işlemi sonucu aktarılacak liste uzayacaktır. Bu da gerisinde gelen bazı önemli bilgilerin aboneye aktarılmasını geciktirebilir. Uzun listeyi yok etmek isteyebiliriz. SQL Server Replication İlgili Notlar makalesinde yazdığımız gibi eğer replicationda o anda bir hata oluşmuşsa ve o hatayı çözemiyorsak replicationun o hatayı atlayıp kuruktaki listeye devam etmesini sağlamak için -SkipErrors parametresini kullanabiliriz. Distribution Agent için tanımlanan bu parametre aracılığıyla sözkonusu hatadaki transactionlar aboneye gönderilmez. Örneğin o anda 2601 (Cannot insert duplicate key row in object ‘%.*ls’ with unique index ‘%.*ls’.) ve 2627 (Violation of %ls constraint ‘%.*ls’. Cannot insert duplicate key in object ‘%.*ls’.) hataların oluştuğunu düşünelim. Bu hataları aşağıdaki gibi atlayabiliriz.
-SkipErrors 2601;2627
Bu yönteme alternatif olarak SQL Server 2005 ile birlikte gelen sp_setsubscriptionxactseqno prosedürü de aynı amaç için kullanılabilir. Bu prosedürün ilk yöntemden farkı non-SQL Server Subscriber’lar için kullanılamıyor olması ve parametre olarak xact_seqno (transaction sequence number) değerini almasıdır. xact_seqno listedeki her transactiona ait
log sequence number (LSN) değerini belirtir. Distribution Agent, Subscriber tarafında en son hangi transaction setini COMMIT etmişse ona ait xact_seqno değerini MSdistribution_history tablosundaki xact_seqno alanına yazar. Bir sonraki transferde bu değerden büyük xact_seqno’lara ait transactionları aboneye gönderir. Veritabanı yöneticisi olarak replikasyonun en son hangi xact_seqno değerinde kaldığını sp_setsubscriptionxactseqno prosedürüyle güncelleyebiliriz.
sp_setsubscriptionxactseqno [ @publisher= ] ‘publisher’, [ @publisher_db= ] ‘publisher_db’, [ @publication= ] ‘publication’, [ @xact_seqno= ] xact_seqno
Bu prosedür sadece transactional replication türünde çalışır.
O andaki hatalı xact_seqno değerlerini bulmak için sp_helpsubscriptionerrors prosedürü kullanılabilir.
sp_setsubscriptionxactseqno yordamına alternatif olarak MSrepl_commands tablosundan kayıt silme yöntemi kullanılabilir. Distribution veritabanının altında bulunan bu tablo replike edilecek komutları içerir. Aşağıdaki gibi xact_seqno değeri verilerek bir transaction set silinebilir.

DELETE FROM MSrepl_commands
WHERE xact_seqno= 0x0008A2500000045A00DE