palkanlaskenta - varchar - smalldatetime/datetime tyyppimuunnosvirhe

[Benkku]

Hei, sama varchar -> smalldatetime/datetime tietotyyppin muunnosvirhe vaivaa edelleen Nova 10 versiossakin. Saisiko tähän 'vihdoinkin' jotain kättäpidempää eli korjauksen sovellukseen ja kannan kenttien tyyppimäärittelyihin. Selkeä syyhän tuossa virheilmoituksessa on. Yritetään castata varchar tyyppistä kenttää päivämäärä tyyppiseksi kentäksi. Suomeksi - jossain kohtaa sovelluskoodia päivämäärämuunnoksessa menee kuukausi ja päivämäärä käsittely ristiin. Teknisesti - kyseessä on arkkitehtuuri vika, jos/kun päivämäärä tietoa tallennetaan varchar tyyppiseen kenttään tai ylipäätään yritetään muuntaa varchar tyyppiä smalldatetime tai datetime tyypiksi. https://database.guide/how-to-specify-the-invariant-culture-when-using-format-in-sql-server/ Tämä ongelma on esiintynyt meillä jo Novan 9.7 versiosta alkane. Kanta toimitettu Vismalle pariinkin otteeseen, eikä vikaa muka löydy. Virheilmoitus lähetettäessä tietoja tulorekisteriin (verkkopalkkalaskelma tökkää myös varchar -> smalldatetime/datetime muunnokseen). ************** Poikkeuksen teksti ************** System.Data.SqlClient.SqlException (0x80131904): Tietotyypin varchar muuntaminen tietotyypiksi smalldatetime antoi tulokseksi arvon, joka ei ole alueella. kohteessa System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) kohteessa System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) kohteessa System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) kohteessa System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) kohteessa System.Data.SqlClient.SqlDataReader.TryHasMoreRows(Boolean& moreRows) kohteessa System.Data.SqlClient.SqlDataReader.TryReadInternal(Boolean setTimeout, Boolean& more) kohteessa System.Data.SqlClient.SqlDataReader.Read() kohteessa System.Data.Common.DataAdapter.FillLoadDataRow(SchemaMapping mapping) kohteessa System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue) kohteessa System.Data.Common.DataAdapter.Fill(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords) kohteessa System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) kohteessa System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior) kohteessa System.Data.Common.DbDataAdapter.Fill(DataTable dataTable) kohteessa Visma.Nova.Common.NovaDatabase.SelectYrDataTable(String sql) kohteessa Visma.Nova.Common.NovaDatabase.SelectDataTable(TargetDb db, String sql) kohteessa Visma.Nova.Common.ReportSummaryCounting.FillDataTable(DataTable& dt, String sXml, String& sReportCount) kohteessa Visma.Nova.Common.ReportSummaryCounting.GetSummaryDatatable(String inXml, String& reportCount) kohteessa Visma.Nova.Common.FormEsikatselu.AddSummary() kohteessa Visma.Nova.Common.FormEsikatselu.FormEsikatselu_Load(Object sender, EventArgs e) kohteessa System.Windows.Forms.Form.OnLoad(EventArgs e) kohteessa System.Windows.Forms.Form.OnCreateControl() kohteessa System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) kohteessa System.Windows.Forms.Control.CreateControl() kohteessa System.Windows.Forms.Control.WmShowWindow(Message& m) kohteessa System.Windows.Forms.Control.WndProc(Message& m) kohteessa System.Windows.Forms.ScrollableControl.WndProc(Message& m) kohteessa System.Windows.Forms.Form.WmShowWindow(Message& m) kohteessa System.Windows.Forms.Form.WndProc(Message& m) kohteessa System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) kohteessa System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) kohteessa System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ClientConnectionId:51e04ac2-84d0-4f98-bab8-adb6f904db4b Error Number:242,State:3,Class:16 ************** Ladatut kokoonpanot ************** mscorlib Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.4075.0 built by: NET48REL1LAST Koodikanta: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll ---------------------------------------- Visma.Nova.Common Kokoonpanon versio: 1.0.0.0 Win32-versio: 1.0.0.0 Koodikanta: file:///J:/Nova/TH/Visma.Nova.Common.DLL ---------------------------------------- Microsoft.VisualBasic Kokoonpanon versio: 10.0.0.0 Win32-versio: 14.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.4001.0 built by: NET48REL1LAST_C Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Core Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.4075.0 built by: NET48REL1LAST Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- NovaNetInterop Kokoonpanon versio: 9.0.0.0 Win32-versio: Koodikanta: file:///J:/Nova/TH/NovaNetInterop.DLL ---------------------------------------- System.Data Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll ---------------------------------------- System.Xml Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Data.DataSetExtensions Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Data.DataSetExtensions/v4.0_4.0.0.0__b77a5c561934e089/System.Data.DataSetExtensions.dll ---------------------------------------- System.Configuration Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Data.resources Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Data.resources/v4.0_4.0.0.0_fi_b77a5c561934e089/System.Data.resources.dll ---------------------------------------- System.Web Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.4075.0 built by: NET48REL1LAST Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_32/System.Web/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Web.dll ---------------------------------------- System.resources Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.resources/v4.0_4.0.0.0_fi_b77a5c561934e089/System.resources.dll ---------------------------------------- DevExpress.XtraGrid.v14.2 Kokoonpanon versio: 14.2.7.0 Win32-versio: 14.2.7.0 Koodikanta: file:///J:/Nova/TH/DevExpress.XtraGrid.v14.2.DLL ---------------------------------------- DevExpress.Data.v14.2 Kokoonpanon versio: 14.2.7.0 Win32-versio: 14.2.7.0 Koodikanta: file:///J:/Nova/TH/DevExpress.Data.v14.2.DLL ---------------------------------------- DevExpress.XtraEditors.v14.2 Kokoonpanon versio: 14.2.7.0 Win32-versio: 14.2.7.0 Koodikanta: file:///J:/Nova/TH/DevExpress.XtraEditors.v14.2.DLL ---------------------------------------- System.Transactions Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_32/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll ---------------------------------------- System.EnterpriseServices Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll ---------------------------------------- System.Runtime.Caching Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Caching/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Runtime.Caching.dll ---------------------------------------- System.Numerics Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll ---------------------------------------- Visma.Nova.Sdk Kokoonpanon versio: 7.0.0.0 Win32-versio: 2019.12.13.1341 Koodikanta: file:///J:/Nova/TH/Visma.Nova.Sdk.DLL ---------------------------------------- mscorlib.resources Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_fi_b77a5c561934e089/mscorlib.resources.dll ---------------------------------------- System.Windows.Forms Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.4042.0 built by: NET48REL1LAST_C Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Windows.Forms.resources Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_fi_b77a5c561934e089/System.Windows.Forms.resources.dll ---------------------------------------- Accessibility Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- System.Drawing.resources Kokoonpanon versio: 4.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing.resources/v4.0_4.0.0.0_fi_b03f5f7f11d50a3a/System.Drawing.resources.dll ---------------------------------------- Visma.Nova.Katre Kokoonpanon versio: 1.0.0.0 Win32-versio: 1.0.0.0 Koodikanta: file:///J:/Nova/TH/Visma.Nova.Katre.DLL ---------------------------------------- Visma.Nova.Core Kokoonpanon versio: 1.0.0.0 Win32-versio: 1.0.0.0 Koodikanta: file:///J:/Nova/TH/Visma.Nova.Core.DLL ---------------------------------------- Microsoft.GeneratedCode Kokoonpanon versio: 1.0.0.0 Win32-versio: 4.8.3752.0 built by: NET48REL1 Koodikanta: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- Ystävällisin terveisin Suomen Vesileikkaus Oy Bengt Ruusunen

[Marko Koivuniemi]

Harmillistahan tämä on, mutta jos vika olisi helposti löydettävissä niin olisihan se jo korjattu. Palkanlaskentaa meilläkin käytetään mutta ei ole tuollaista tullut koskaan vastaan. Olisiko mahdollista että palvelimen ja/tai työaseman päiväys/kieliasetuksissa on jokin asetus väärin? Tuleeko virhe joka palkanlaskennan operaatiossa vaiko vain satunnaisesti? Vai kenties jotain tiettyä raporttia tulostaessa? Miten tilanteesta toivutaan?

Sorkkiiko joku muu ohjelma teidän Nova-kantaa - ts. tuleeko palkanlaskentaan tietoja jostain muusta järjestelmästä? Näitä asioita varmaan on käsitelty kun kerran tietokantaakin ovat tutkineet ja joskus se on tuskallista. Meilläkin on ollut muutamia veemäisiä bugeja joita ei vain saatu toistettua millään kehityksessä ja kesti kauan että löytyi oikea yhdistelmä jossa bugi saatiin esille. Ettei kuitenkin kyse olisi jostain toimintatavasta jossa tehtään asioita niin kuin ne on aina tehty koska se on toiminut ja tuo operaatio hajosi versiossa 9.7. Itse tietokannassa palkka-taulussa on kyllä päivät ovat smalldatetime. Itsekin kun sql-skripteillä käsittelene niin usein on helpompaa käsitellä niitä merkkijonoina. Näetkö missään virheessä itse tietokannan kenttää josta virhe tulee? Jos sinulla on pääsy sql-kantoihin niin voisimme tehdä vertailevia kyselyitä josko löytyisi joku. Kyse voi hyvinkin olla esim. yhden työntekijän tietoihin liittyvästä asiasta tai jostain muusta jota ei nyt vain osata ajatella.

[Benkku]

Tätä on tutkittu, sekä Visman että meidän toimesta. Lokaaliasetukset työasemassa ja palvelimessa ok (Finnish), kellonajan erotin Win10 käyttöjärjestelmässä asetettu kaksoispisteeksi. Palkanlaskentaan tuntipalkkalaisille tuodaan tuntitiedot Ellistä. Aineiston muodostusta on testattu rajaamalla vain yhteen henkilöön, virhe esiintyy poikkeuksetta riippumatta valitusta henkilöstä tai päivämäärärajauksesta, kun päivämäärärajaus ylittää 12. Virhe melko varmasti johtuu sovelluksesta, kannan päivämääräkenttien ollessa smalldatetime tai datetime tyyppiä, niin miksi sovelluksessa niitä ensin käsitellään varchar tyyppisinä ja yritetään muuntaa päivämäärätyypiksi. Tällöin tuo virheilmoituksen invariant lokaalivirhe on mahdollinen. Tyypitettyjä päivämääräkenttiä ei pitäisi käsitellä varchar tyyppisinä. Aikoinaan ehdotin Vismalle päivämääräkäsittelyjä tehtävän ISO8601 muodossa, jolloin virhettä ei millään lokaalikombinaatioilla esiintyisi. Palkkalaskelma tulostuu paperille ok (PL.exe vb6 sovellus), mutta .net koodi jolla muodostetaan sähköistä aineistoa aiheuttaa virheen.

[Benkku]

Tähän vielä lisäyksenä. SELECT default_language_name FROM sys.server_principals Kannan (domain kirjaus) käyttäjillä kieliasetuksena on Suomi, poislukien sa, jolla us_english.

[Marko Koivuniemi]

Meidän nykyinen tuotantopalvelin (Sqlserver 2017) ja entinen (Sqlserver 2008R2) tarjoavat principaleiksi us_englishia. Tietokantojen collation-asetukset on toki määritelty ohjeiden mukaan Finnish_Swedis_blaablaaksi . Mutta minä en tiedä näistä tietokantamoottorien konepellin alaisista jutuista tarpeeksi sanoakseni juuta tai jaata että voisiko tuo jopa vaikuttaa. Toivottavasti tämä ketju on kehittäjienkin seurannassa.

Ohjelmoinnissa on monta tapaa tehdä asioita ja sanoisin että tyypinmuunnos on erinomainen työkalu monissakin tapauksissa - se toimii testinä mitä kenttä sisältää. Itsekin käytän sitä eräissä raporttipohjissa jossa saan tutkittua onko neljä merkkiä alusta vuosiluku vaiko ei.

Tässä tapauksessa tuo virheilmoitus ei mielestäni ole osoitus siitä että tyypinmuunnos itsessään on väärin vaan seuraus jostain syystä, jonka toki pitäisi osata antaa järkevämpi virheilmoitus. 

[Benkku]

Kannan taulujen kentät jo lähtökohtaisesti sisältävät päivämäärätietueen. Ooletettavasti kaikkien palkanlaskennan taulujen päivämääräkentät ovat joko smalldatetime tai datetime tyyppiä. Mikäli näin ei ole, on kyseessä mielestäni arkkitehtuurivirhe. Kenttien tietuetyyppien ollessa määritetty oikein, ei dataa tarvitse/pidäkään castata varchar tyypistä datetime tyypiksi. Toisinsanoen kannan dataa pitäisi sovelluksessa käsitellä päivämäärätyyppinä ei muuttuvapituisena tekstikenttänä, jota sovelluksessa mitä ilmeisemmin (virheilmoitus) yritetään muuntaa päivämäärämuotoon. Sovelluksessa viimekädessä tehdään virheen aiheuttava muunnos. Mikäli näin kuitenkin syystä tai toisesta tehdään, tulisi käyttää ns. invariant locale muunnosta kts. linkki ylempää.

[Marko Koivuniemi]

Ymmärrän kyllä mitä sanot, mutta tuo koska samainen ohjelma toimii mitä ilmeisimmin valtaosalla muista käyttäjistä/asiakkaista/ympäristöistä ihan oikein niin tämä (kenties pohjimmiltaan jo hyvinkin vanhaa perua oleva) ohjelmointitekninen epäeleganssius (kenties jopa purkka) ei ole se vian juurisyy. Miten tiketti suljettiin viimeksi - saivatko toistettu asian teidän kannallta Visman ympäristössä?  

[Benkku]

Ohjelma 'toimii' vaikka siinä olisi vikaa, senhän jokainen meistä tietää tai sitten tökkää virheeseen, jolloin vika eskaloituu. Otetaan vielä kerran uusiksi, palkkaohjelman (pl.exe) käyttämää SQL hakua esimerkkinä käyttäen; SELECT DISTINCT PKausi.Numero FROM Pkausi INNER JOIN Ptapah ON Ptapah.Numero = Pkausi.Numero INNER JOIN PLHenkilo ON PKausi.Hnro = PLHenkilo.Hnro WHERE ..... PKausi.MaksuPvm BETWEEN 'alkupvm' AND 'loppupvm' Tässä siis alku- ja loppupvm muuttujan arvot hakulausessa paljaana merkkijonona. Vikana ettei oikeata päivämäärätyyppimuunnosta SQL serverille hakulauseessa tehdä (Cast tai Convert) puuttuu, vaan hakulauseeseen tarjotaan sovelluksessa määritettyä 'päivämäärä' merkkijonoa. Toisinsanoen alkupvm ja loppupvm muuttujien tulisi olla explisiittisesti castattu käyttäen invariant lokaalia päivämäärää. esim. BETWEEN CONVERT(SMALLDATETIME, 'yyyy-mm-dd', 126) 'ISO8601 AND CONVERT(SMALLDATETIME, 'yyyy-mm-dd', 126) Sama vika toistuu mm. myös allaolevissa hakulauseissa SELECT PTapah.* FROM Ptapah LEFT JOIN PKausi ON Ptapah.Numero = Pkausi.Numero LEFT JOIN PLHenkilo ON Ptapah.Hnro = PLHenkilo.Hnro WHERE .... ja SELECT Pkausi.* FROM Pkausi WHERE ....." AND PKausi.MaksuPvm BETWEEN ....

[Marko Koivuniemi]

Tämä on selvä tapaus että parempi menetelmä päivämäärien käsittelyyn olisi olemassa. Mutta eihän tuo aiheuta ongelmia ellei jossain muussa kohdassa tietokantaan tallennu Novan kannalta vääräntyyppistä dataa ja vika on silloin jossain muussa kuin tuossa tyypinmuunnoksessa itsessään. Onko teidän tietokannassa siis päivämääriä väärässä formaatissa - jolloin tuo tyypinmuunnospäivitys auttaisi - vai onko siellä arvoja jotka aiheuttaisivat joka tapauksessa virheitä? Jos ensimmäinen vaihtoehto, niin avainkysymys on että miksi päivämäärät muodostuvat väärässä formaatissa?

Meidän tietokannasta ei löydy päivämääriä muissa formaateissa kuin tuossa jota Novakin nieleskelee ja jos on tällä hetkellä niin ettei Nova muuta nieleskele niin sen kanssa on elettävä.

[Marko Koivuniemi]

Hävettävistä ajatuskatkoksista huolimatta (tietokannassa tietysti smalldatetime kentässä tieto on päivämääränä jos yleensä on) itse ydinasia pätee: Joka tapauksessa päiväys tarjoillaan nyt Novalle väärässä muodossa ja vaikka se on toki korjattavissa myös Novan ohjelmoinnin muutoksella oikeaoppisempaan muotoon, niin palvelinpään asetuksissahan se vika täytyy majailla ja helpompi muutos tässä vaiheessa on saada palvelimeen. Mietin että jos teen testikannan ja muutan siihen default principaliksi suomen ja kokeilen tehdä samoja operaatioita. Voihan pam pam pam pam Pamela.... (Victoria Principal) ku ihania tällaiset.

[Benkku]

Kantapalvelimen kieliasetukset sys.databases eli tietokantojen asetukset NAME COLLATION_NAME master Finnish_Swedish_CI_AS tempdb Finnish_Swedish_CI_AS model Finnish_Swedish_CI_AS msdb Finnish_Swedish_CI_AS Nova Finnish_Swedish_CI_AS YR0 Finnish_Swedish_CI_AS YR1 Finnish_Swedish_CI_AS YR2 Finnish_Swedish_CI_AS VDC_SYSTEMDB Finnish_Swedish_CI_AS YR3 Finnish_Swedish_CI_AS YR4 Finnish_Swedish_CI_AS sys.server_principals eli käyttäjien kieliasetukset name default_language_name XXXXX\novasuperuser Suomi XXXXX\novabookkeeper Suomi XXXXX\novauser Suomi XXXXX\novabankuser Suomi XXXXX\novabanksuperuser Suomi XXXXX\novabankuserread Suomi XXXXX\novaledger Suomi XXXXX\novacashier Suomi XXXXX\novapayroll Suomi XXXXX\novatravellexpenses Suomi XXXXX\novabookkeeperread Suomi XXXXX\novastock Suomi XXXXX\novaproduction Suomi XXXXX\novaplan Suomi XXXXX\NovaSales Suomi XXXXX\NovaSalesread Suomi XXXXX\NovaPurchase Suomi XXXXX\NovaWOKAcceptor Suomi XXXXX\NovaDashboard Suomi

[Marko Koivuniemi]

Collation-asetukset ovat samat mutta tosiaan meillä on molemmissa sqlserver-palvelimissa myös Nova-kannoissa default_language_name-kentän arvona: us_english.

En osaa sanoa onko tuo merkittävä ero tai olenko minä tai joku muu tehnyt jotain aikoinaan väärin.

[Benkku]

Kyllä tuo kannan default collation asetus vaikuttaa ja se on meidän mielestä teilla väärin. Suomessa kun ollaan. Testasin tätä vielä niin, että loin kantaan palkanlaskijalle domain login tunnuksen XXXX\kayttaja jolle määritin oletuskieleksi (Default language) English. Yllätys yllätys, varchar datetime muunnosvirhettä ei esiintynyt ja aineisto (verkkopalkkalaskelma sekä tulorekisteri-ilmoitus) tuli esikatseluun ja meni läpi.

[Marko Koivuniemi]

Summa summarum. Eikös tämä nyt tarkoita sitä että ongelmaan löytyi sekä syy että nopea ratkaisu. Onko ratkaisu lopullinen vai tarttuuko Visma koodinsiivoustalkoisiin on sitten muiden käsissä.  Novan asennusoppaissa ei ole mainintaa noista "default collation" -asetuksista. Olisiko mahdollista että siihen maailman aikaan kun Nova siirtyi sqlserveriin (eli vuosituhannen alussa sqlserverin versiossa 2000 /ja Novan versiossa 6 ) oli "default collation" us_english ja siksi Novakin rakentuu sen varaan? En tiedä. Tosin nuo toiminnot jotka nyt aiheuttavat ongelmia ovat varmasti tuoreempia.

[Benkku]

Mielestäni tämä on 'vain' kiertotie ongelman ratkaisemiseksi, Sen tämä käyttäjän login testi osoittaa. Toisinsanoen Visma Nova järjestelmä - ainakin palkanlaskennan osalta käsittelee päivämääriä virheellisessä muodossa. Tätä asiaa on meillä vatvottu jo kolmen tiketin verran, edellisen kerran viime keväänä. Visma ei ongelmaa ole saanut ratkaistua.

[Marko Koivuniemi]

Olin pilotoimassa Nova 10:ä - ja katsoin juuri virtuaalipalvelimelta johon asensin testiä varten puhtaalta pöydältä ohjeiden mukaan Sqlserverin 2014 Developer Express -version ja sielläkin on palvelimen oletuskielenä englanti ja "vain" server collation asetuksena Finnish_Swedish_CI_AS. Eli oletustilanteessa ja ohjeiden mukaisessa asennuksessa Nova toimii halutulla tavalla. Jos asiat on tehty ohjeiden vastaisesti niin korjaava toimenpide ei ole kiertotie vaan korjaus. Päivämäärien käsittely toimii tilanteissa joissa järjestelmää on käytetty oikein - ja vaikka huomiosi päivämäärien käsittelystä onkin sinänsä täysin oikea niin em. seikat tekevät asiasta lähinnä kehitysehdotuksen eikä vian. Koko tietokantamoottorin asetuksien muuttaminen voi aiheuttaa muitakin seurauksia ziljoonassa paikkaa joten en ihmettele ettei siihen kevyesti lähdetä. Novan koodiriveissä kun voi olla hyvinkin vanhoja vuosikerrostumia...

[Benkku]

Novan asennusohjeessa tietokantamoottorin asennuksesta (Asennusopas.pdf), sivulla 9 mainitaan. 10. Määrittele Collation-välilehdellä Database Engine- kohdassa Finnish_Swedish_CI_AS, painamalla Customize…. Kun Collation-asetukset on määritelty, jatka asennusta painamalla Next. Luonnollisesti Windows palvelimen maa-asetukset (meillä Server 2012 R2) määritetään lokaalin mukaisiksi, poikkeuksena uusimmissa (Win10 versioon perustuvissa järjestelmissä) kellonajan esitysmuoto, jossa erotin muutetaan pisteestä kaksoispisteeksi.

[Benkku]

Tässä testissähän ei kantamoottorin collation asetukseen edes koskettu, vaan vain käyttäjän loginin default language ts. maa-asetus muutettiin Finnish -> English.

[Benkku]

Vastaan tähän vielä erikseen. Lainaus ohjeiden mukaisessa asennuksessa Nova toimii halutulla tavalla. /Lainaus Asennusympäristössämme Nova kantojen collation asetus on määritetty Novan asennusohjeen mukaisesti eli Finnish_Swedish_CI_AS. kts. viestit ylempää.

[Benkku]

Vastaan tähän vielä yleisemmin/laajemmin. Olin pilotoimassa Nova 10:ä - ja katsoin juuri virtuaalipalvelimelta johon asensin testiä varten puhtaalta pöydältä ohjeiden mukaan Sqlserverin 2014 Developer Express -version ja sielläkin on palvelimen oletuskielenä englanti ja "vain" server collation asetuksena Finnish_Swedish_CI_AS. Eli oletustilanteessa ja ohjeiden mukaisessa asennuksessa Nova toimii halutulla tavalla. SQL server collation asetus ei tässä asiassa vaikuta, vaan viimekädessä nimenomaan kannan ja käyttäjätunnuksen collation asetus. Palvelimen collation asetus vaikuttaa vain, mikäli kannan collation asetusta ei ole määritetty ts. on default asetuksella, jolloin kannan collation asetus määrittyy server asetuksen mukaiseksi.

[Benkku]

Linkki..... https://docs.microsoft.com/en-us/sql/relational-databases/collations/set-or-change-the-database-coll... ....... database collation in SQL Server 2019 (15.x) by using SQL Server Management Studio or Transact-SQL. If no collation is specified, the server collation is used. .... Toiminta on sama myös vanhemmissa SQL Server versioissa, meillä käytössä 2017 (RTM-CU18) (KB4527377) - 14.0.3257.3 (X64) eli viimeisin korjauspäivitys. https://support.microsoft.com/en-us/help/4047329/sql-server-2017-build-versions