Number column, when saved – inserts comma – read by DF as a decimal

› Forums › Classic DFFS › Number column, when saved – inserts comma – read by DF as a decimal

Tagged: ,

Viewing 8 reply threads
  • Author
    Posts
    • April 29, 2015 at 16:44 #7490
      iain.stephen@msdsb.net
      Participant

      Hello,

      I have some forms with number columns in them using dynamic forms – when a user enters a simple number using newform – like 225000 – saves it – then goes back to edit it in editform, or even view it in dispform – the SP has inserted a comma to separate the thousands – and DF rules read that comma as a decimal – as per debug below: (this then breaks the rule which is looking for <150000 – as it reads it as 225.000 – or 225 and returns true – when it should be false)

      Rule “El3Assessed Value” (load)
      Triggerfield: Which_x0020_best_x0020_describes
      Current value: 225.000
      Operator: Leq
      Target value: 150000
      match: true

    • April 30, 2015 at 15:28 #7504
      Alexander Bautz
      Keymaster

      Hi,
      I have tried to fix this in the v4.268 update of DFFS frontend. You find the change log here: https://spjsblog.com/dffs/dffs-change-log/

      Let me know how this works out.

      Best regards,
      Alexander

    • May 4, 2015 at 19:01 #7534
      iain.stephen@msdsb.net
      Participant

      The issue does not appear to have been resolved – once the comma is inserted (result of saving the newform.aspx) – it is still being read as a decimal on edit or display forms – so the rules with less than, equals, greater than in the form do not work properly.

      Confirmed that version on this subsite is in fact v4.268

    • May 4, 2015 at 19:37 #7549
      Alexander Bautz
      Keymaster

      Which number format are you using (locale settings in SharePoint)? – it looks like your number is in fact 225 and not 225000. You might have to change the locale in SP, or enter the number in another manner.

      You can also use a single line of text field to store this value as SharePoint will not mess with the format in a text field.

      Alexander

    • May 4, 2015 at 20:08 #7550
      iain.stephen@msdsb.net
      Participant

      The subsite’s regional settings – under locale – set to English (United States)… We are Canadian but I don’t have English (Canada) to choose from…

      If I change the locale – what do I change it to, and how will it affect other parts of the subsite?

      The number is saved as 225000 (value of your home). When saved, SP automatically inserts the comma to separate the thousands. Edit and Disp form are reading the comma as a decimal… You are welcome to have a look if it will help – let me know.

    • May 4, 2015 at 20:11 #7556
      iain.stephen@msdsb.net
      Participant

      Also – I will assume that if I change the field type to single line of text now, I will lose the data in the existing column? Trying to avoid that as this is live, in production.

    • May 5, 2015 at 07:37 #7560
      Alexander Bautz
      Keymaster

      Hi,
      I had a bug related to the operators “Gt”, “Geq” and “Leq” in the latest “fix” – please check if this sorts out some of these issues: https://spjsblog.com/dffs/dffs-change-log/

      Best regards,
      Alexander

    • May 5, 2015 at 22:44 #7568
      iain.stephen@msdsb.net
      Participant

      You were absolutely correct – it was the GT, LT and GTE/LTE issue – it is now working with the latest download.

    • May 7, 2015 at 16:35 #7579
      Alexander Bautz
      Keymaster

      Thank you for the feedback.

      Alexander

  • Author
    Posts
Viewing 8 reply threads
  • You must be logged in to reply to this topic.