Model temelli uygulamalarda tarih ve saat sorunlarını giderme

Tarih ve saat değerleri bir gün veya birkaç saat kapalı olduğunda, bunun nedeni saat dilimi veya yaz saati ayarlamaları olabilir. Bu makalede, aşağıdakiler gibi sorunları gidermeye yönelik ipuçları sağlanır:

• Tarih ve Saat alanı yanlış değeri gösteriyor.
• Yalnızca tarih değeri bazı kullanıcılar ve saat dilimleri için yanlış tarihi gösterir.
• Tarih ve Saat alanı, uygulamanın bazı bölümlerinde doğru değeri gösterir, ancak diğer bölümlerinde gösterilmez.
• Tarih ve saat değerini değiştirip kaydettikten sonra, otomatik olarak farklı bir değere dönüşür.
• Gün ışığından yararlanma geçiş tarihi girildiğinde tarih bir gün kapalı olur veya saat bir saat kapalı olur.

Bunun bir sunucu veya istemci sorunu olup olmadığını belirleme

Model temelli uygulamalar web uygulamalarıdır. Dataverse bulut hizmetinden (sunucudan) veri alır. Aynı veriler birden çok uygulamayı (istemci) güçlendirebilir. Sunucuda veya istemcide hatalar oluşabilir.

Sunucuda depolanan tarih ve saat değeri beklenmedikse, kullanıcı veya sistem saat diliminden bağımsız olarak tüm uygulamalarda yanlış görünür. Bu nedenle, sunucu değerini doğrulamak önemli bir ilk adımdır.

Tarih ve saat sütununun yapılandırmasını denetleme

Dataverse, tarih ve saat sütunları (alanlar) için farklı saat dilimi ayarlama davranışlarını destekler. Sorun giderme işleminden önce, sistemdeki farklı bölümlerin tarih ve saat değerlerini nasıl işlediğini anlamak önemlidir.

Power Apps portalında veya çözüm gezgininde tarih ve saat sütunu seçeneklerini denetleyin:

• Kullanıcının saat dilimini hesaplayıp hesaplamayacağı
• Değerin saat bölümünü görüntüleyip görüntülemediği

Doğru değerin sunucuda depolanmış olup olmadığını denetleyin

Tarih ve saat değerleri her zaman sunucuda UTC olarak depolanır. Ham değeri bir Web API sorgusuyla sunucuda görüntüleyebilirsiniz.

Bir satır (kayıt) için sütun almak için bir sorgu aşağıdadır.

[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>

Kullanılan tablo ve sütun adları, görünen adlar değil mantıksal adlardır.

İpucu

Bir satırın kimliğini bulmanın kolay bir yolu, bunu model temelli bir uygulamada açmaktır. Kimlik, sayfa URL'sinde bulunabilir.

Aşağıdaki örnek, kimliğine scheduledstart d2862246-4763-ee11-8def-000d3a34118bsahip satırın tablosunun sütununu appointment alır.

https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart

Bunu tarayıcı adres çubuğuna girdiğinizde aşağıdakine benzer bir şey gösterilir:

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "d2862246-4763-ee11-8def-000d3a34118b"
}

Bu nedenle, scheduledstart appointment 15 Ekim 2023, 07:30'dır. Z sonunda değerin UTC olarak olduğunu gösterir.

Utc-8 saat dilimindeki bir kullanıcının model temelli bir uygulamada bu sütunu görüntüledi olduğunu düşünelim. Bunlar, farklı sütun seçenekleri için beklenen değerlerdir.

Saat dilimi ayarlama davranışı	Biçimlendir	Uygulamada gösterilen değer
Kullanıcının Saat Diliminde	Tarih ve saat	14 Ekim 2023, 23:30
Kullanıcının Saat Diliminde	Yalnızca tarih	14 Ekim 2023
Saat Diliminden Bağımsız	Tarih ve saat	15 Ekim 2023, 7:30
Saat Diliminden Bağımsız	Yalnızca tarih	15 Ekim 2023
Yalnızca tarih	-	15 Ekim 2023

Uygulamada gösterilen değer doğru ayarlanmamışsa, büyük olasılıkla bir istemci sorunudur. İlk olarak sunucu değeri yanlışsa, büyük olasılıkla bir sunucu sorunudur.

Sunucudan biçimlendirilmiş değeri denetleyin

Saat dilimi ve gün ışığından yararlanma ayarlamaları sunucuda veya uygulamada yapılabilir. Aynı sütunda uygulamanın farklı bölümlerinde farklı bir değer gösteriliyorsa, uygulamanın bazı bölümleri sunucudan biçimlendirilmiş değeri kullanırken, diğerleri uygulamada ayarlamalar yapıyor olabilir.

Bu büyük olasılıkla bir sorundur. Raporlamadan önce, biçimlendirilmiş değeri sunucudan denetleyerek bunun bir sunucu mu yoksa istemci sorunu mu olduğunu yalıtabilirsiniz.

Örneğin,

GET https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Yanıt, sunucu tarafından ayarlanan değeri içerir. Bu örnekte, kullanıcı UTC-8 saat dilimindedir ve scheduledstart Kullanıcı Yerel davranışına sahiptir. Bu nedenle, biçimlendirilmiş değer ham değerin sekiz saat gerisindedir.

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart@OData.Community.Display.V1.FormattedValue": "10/14/2023 11:30 PM",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "2ad8786a-9164-ee11-9ae7-0022480a0700"
}

Biçimlendirilmiş bu değer yanlışsa, bu bir sunucu sorunudur. Doğruysa, bu bir istemci sorunudur.

Beklenmeyen sunucu değerlerini araştırma

Beklenmeyen sunucu değerlerinin olası nedenleri şunlardır:

• Saat dilimi ayarlama davranışını ve biçimini doğru yapılandırmamış olabilirsiniz.
• Sunucuda çalıştırılan iş kuralları ve iş akışları , kaydedilmeden önce veya kaydedildikten sonra değeri değiştirebilir. Bir uygulamanın içinde, istemci betikleri değeri kaydetmek üzere sunucuya göndermeden önce değiştirebilir.

Bunun bir özelleştirme sorunu mu yoksa ürün sorunu mu olduğunu belirleme

Özelleştirmeler beklenmeyen davranışlara yol açabilir. Aşağıdaki yöntemler, özelleştirmelerin neden olduğu sorunları eleyebilir.

Özel betikleri devre dışı bırakma

Özel betikler genellikle sorunlara neden olur. Bunları geçici olarak devre dışı bırakmayı deneyin.

Yeni tarih ve saat sütunu oluşturma

Yeni tarih ve saat sütunu oluşturmak, sorunun yapılandırma hatalarından mı yoksa iş kuralları gibi özelleştirmelerden mi kaynaklanıp kaynaklanmadığını öğrenmenin en kolay yoludur. İdeal olarak, farklı bir tablo ve uygulama kullanın.

Yeni sütun beklendiği gibi çalışıyorsa, büyük olasılıkla bir özelleştirme sorunudur. Farkı bulmak için özgün sütunla karşılaştırın.

Yeni sütunda aynı sorun varsa, bu bir ürün sorunu olabilir. Vanilya repro model temelli bir uygulama oluşturabilir ve bunu bir destek isteği aracılığıyla raporlayabilirsiniz.

Farklı bir saat dilimini deneyin

Saat dilimi ve yaz saati ayarlamalarının beklenmeyen değerlere neden olup olmadığını öğrenmek için kullanıcının saat dilimini değiştirmeyi deneyin.

Model temelli uygulamalarda saat dilimlerini etkileyen iki ayar vardır:

1. Kişisel seçeneklerde saat dilimi.
2. Sistem saat dilimi. Değiştirme hakkında bilgi için Windows, Android, iOS veya macOS'taki ilgili belgelere bakın.

Denemek için yararlı birleşimler:

• Kişisel seçeneklerdeki saat dilimini sistem saat dilimiyle eşleştirin.
• UTC saat dilimini kullanın.
• Aynı uzaklığı olan bir saat dilimi kullanın, ancak gün ışığından yararlanmayı gözlemlemez.

İpucu

Aşağıdaki yöntemler, tarih ve saat sorunlarını araştırmayı kolaylaştırmak için daha fazla ayrıntı sağlar.

• "Yalnızca Tarih" biçimini "Tarih ve Saat" olarak değiştirin
• 2 basamaklı yılları kullanmayın

"Yalnızca Tarih" biçimini "Tarih ve Saat" olarak değiştirin

Yalnızca tarih değeri bir güne göre kapalıysa, nedenin saat dilimi ayarlamaları olup olmadığını görmek için saat bölümünü göstermek yararlı olur. Power Apps portalında veya çözüm gezgininde sütun biçimini geçici olarak değiştirebilirsiniz.

2 basamaklı yılları kullanmayın

2 basamaklı yıl belirsizdir. Örneğin, 40 1940, 2040 veya 2140 anlamına gelebilir. Sistemin 2 basamaklı yılları yorumlama şekli zaman içinde değişebilir ve büyük olasılıkla değişebilir.

Ayrıca, tam tarih ve saat değerlerinin ne zaman gösterilmediğinden de araştırmak zordur. Bu nedenlerden dolayı, özellikle tarih girerken 4 basamaklı yıl kullanılması kesinlikle önerilir.

Kalıcı olarak 4 basamaklı yıllara geçemiyorsanız, sorun gidermeye yardımcı olmak için geçici olarak deneyin.

Ayrıca bkz.

Tarih ve Saat sütununun davranışı ve biçimi