web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Apps / Date year getting mess...
Power Apps
Unanswered

Date year getting messed up writing to SQL Server

(0) ShareShare
ReportReport
Posted on by 418

Hello - We have a powerApp that writes to a SQL Server DB.  Most users are successful when writing to the DB.  A handful are experiencing an issue where the date column(s) is putting in the year as 1477 instead of 2020.  As you could imagine this is a problem.  The column definitions are as follows.  ForecastYear: year the forecast is for, ForecastMonth: Month the forecast is for, ReportingForecastDate: the first day of the month for the given years forecast, CurrentForecastDate: todays date, SixtyDayForecast: todays date (Null is also acceptable).  ForecastYear and ForecastMonth are both good but ReportingForecastDate, CurrentForecastDate and SixtyDayForecast are wrong.  

 

EDIT (5/27/20): I have found what I think to be causing the problem.  I would enjoy hearing anyone suggestion on to fix it or if they ran into a similar issue.  

 

I have narrowed it down to users who have their language set to "Thai".  Thai uses a calendar that is 543 years behind the Gregorian calendar, thus the year 1477.  Using the debugger (or whatever it is called) I see PowerApps creates a header "language" when sending to the SQL server API/Connector.  My guess is this header is used in SQL server when creating the date, and this is what is causing my issue.  

 

I could try and add 543 years onto each date if the PowerApps Language() function evaluates to "th".  However, to me, this seems like a temporary fix.  Another language could use a calendar different than Gregorian and I would need to implement custom code for every language that differs.  Ideally I would want to override language or be able to exclude that header in the SQL Server API/Connector.  

 

Thanks for any insight!

 

Would really appreciate any help/insight.

 

Code to collect the record:

 

Collect(toAdd, {SalespersonId:varCurrentUser.SalespersonId, CustomerId:ThisItem.CustomerId , CustomerShipToId:ThisItem.CustomerShipToId ,BUAreaCode:ThisItem.BUAreaCode , BUManagementGroupCode:ThisItem.BUManagementGroupCode, ItemId:ThisItem.ItemId, ForecastYear:Value(Text(DateAdd(Now(), 5, Months), "[$-en-US]yyyy")), ForecastMonth:Value(Text(DateAdd(Now(), 5, Months), "[$-en-US]m")), CurrentForecastQty:Value('txtFData-M5'.Text), SixtyDayForecastQty:Value('txtFData-M5'.Text), CurrentForecastDate:Today(), SixtyDayForecastDate:Date(Value(Text(DateAdd(Now(), 0, Months), "[$-en-US]yyyy")), Value(Text(DateAdd(Now(), 0, Months), "[$-en-US]m")), Value(Text(DateAdd(Now(), 0, Months), "[$-en-US]d"))), ReportingForecastDate:Date(Value(Text(DateAdd(Now(), 5, Months), "[$-en-US]yyyy")), Value(Text(DateAdd(Now(), 5, Months), "[$-en-US]m")), 1) })
)

 

 How the SQL Server Record Looks:

BadDates.PNG

Categories:
I have the same question (0)
  • v-bofeng-msft Profile Picture
    on at

    Hi @samuelJ :

    Could you tell me what these fields’ data types are?( CurrentForecastDate, SixtyDayForecastDate, ReportingForecastDate)

    Do you want to enhance the robustness of the code so that all users can get the correct results?

    I made a similar test but did not encounter the problem you mentioned.

    I suggest you to troubleshoot the problem from two aspects:

    1\Convert the data types of these three fields to date type (if they are not date types)

    2\Use a more standardized function instead of the TEXT function.

    According to your statement, most users run correctly, and a group of users get the wrong results. This shows that the problem is caused by differences in equipment (users). My guess is that the Text function's recognition of different date formats for different users caused the difference.

    I suggest you try this code:

    Collect(toAdd, {
     SalespersonId: varCurrentUser.SalespersonId,
     CustomerId: ThisItem.CustomerId,
     CustomerShipToId: ThisItem.CustomerShipToId,
     BUAreaCode: ThisItem.BUAreaCode,
     BUManagementGroupCode: ThisItem.BUManagementGroupCode,
     ItemId: ThisItem.ItemId,
     ForecastYear: Year(DateAdd(Today(), 5, Months)),
     ForecastMonth: Month(DateAdd(Today(), 5, Months)),
     CurrentForecastQty: Value('txtFData-M5'.Text),
     SixtyDayForecastQty: Value('txtFData-M5'.Text),
     CurrentForecastDate: Today(),
     SixtyDayForecastDate: Today(),
     ReportingForecastDate: Date(Year(DateAdd(Today(), 5, Months)), Month(DateAdd(Today(), 5, Months)), 1)
    })

    I think this link will help you a lot:

    Day, Month, Year, Hour, Minute, Second, and Weekday functions in Power Apps

    Best Regards,

    Bof

  • SJ-15052312-0 Profile Picture
    418 on at

    Hello @v-bofeng-msft ,

     

    I do agree that it could be a hardware problem, as not all users experience this.  CurrentForecast, SixtryDateForecast and reportingforecast are all date type columns in SQL Server.  

     

    I do not think the given solution will work.  CurrentForecast column is already using the today() function and it is not providing the correct date of today.  So I don't see the need to try it on sixtyDayForecast. 

     

    Any other insight?  It very difficult to trouble shoot on my end as I, personally, can not recreate on my machine what is happening.    

  • v-bofeng-msft Profile Picture
    on at

    Hi @samuelJ :

    Can you tell me what the data type of these fields is?(CurrentForecastDate,SixtyDayForecastDate……)Date?Or Char?

    Best Regards,

    Bof

  • SJ-15052312-0 Profile Picture
    418 on at

    @v-bofeng-msft date.

  • SJ-15052312-0 Profile Picture
    418 on at

    The users who are reporting this have their language settings to Thai.  I think this is causing the issue, as that language uses the formatting of ddmmyyyy.  I am able to recreate the issue by setting my google chrome settings to thai as the default language.  I have tried using formatting of "en-US" but this still not working.  Appreciate any insight.  

  • SJ-15052312-0 Profile Picture
    418 on at

    Hello - I have found what I think to be causing the problem.  I would enjoy hearing anyone suggestion on to fix it or if they ran into a similar issue.  

     

    I have narrowed it down to users who have their language set to "Thai".  Thai uses a calendar that is 543 years behind the Gregorian calendar, thus the year 1477.  Using the debugger (or whatever it is called) I see PowerApps creates a header "language" when sending to the SQL server API/Connector.  My guess is this header is used in SQL server when creating the date, and this is what is causing my issue.  

     

    I could try and add 543 years onto each date if the PowerApps Language() function evaluates to "th".  However, to me, this seems like a temporary fix.  Another language could use a calendar different than Gregorian and I would need to implement custom code for every language that differs.  Ideally I would want to override language or be able to exclude that header in the SQL Server API/Connector.  

     

    Thanks for any insight!

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Forum hierarchy changes are complete!

In our never-ending quest to improve we are simplifying the forum hierarchy…

Ajay Kumar Gannamaneni – Community Spotlight

We are honored to recognize Ajay Kumar Gannamaneni as our Community Spotlight for December…

Leaderboard > Power Apps

#1
WarrenBelz Profile Picture

WarrenBelz 721 Most Valuable Professional

#2
Michael E. Gernaey Profile Picture

Michael E. Gernaey 320 Super User 2025 Season 2

#3
Power Platform 1919 Profile Picture

Power Platform 1919 268

Last 30 days Overall leaderboard