Editor.NET with oracle dropping commas from string fields
Editor.NET with oracle dropping commas from string fields

I'm using the most recent version of editor.NET with an oracle database. DB Field type is varchar2(200).
Using a model in editor with the variable declared as a string
public class wf_lov
{
[MaxLength(32)]
public string rtn_column_comp { get; set; }
}
***** snip ****
[Route("api/LOV/{id:int?}")]
[HttpGet]
[HttpPost]
public IHttpActionResult LOV(int? id = null)
{
var settings = Properties.Settings.Default;
var request = HttpContext.Current.Request;
using (var db = new Database(settings.DbType, settings.DbConnection))
{
Editor editor = new Editor(db, "wf_lov")
.Model<wf_lov>();
editor.Process(request);
return Json(editor.Data());
}
}
The datatable itself is setup the same as the basic example. When I edit the rtn_column_comp field if I enter 1,3 it strips the comma out before it saves in the database. If I enter 1,A it's works fine.
This question has an accepted answers - jump to answer
This discussion has been closed.
Answers
Does it save as
1.3
,1
or13
?Also what is the "culture" that your server is set up as? I ask as when data is entered it will attempt to do
return Convert.ToInt32(dataIn);
, which I think might be causing the issue (depending on if the server is treating the,
as a decimal character or not.Allan
It saves 1.3 correctly. Regional settings are en-AU so numbers should typically be in the format
1,000.25
Looks like the Convert.ToDecimal function is what strips the comma out. Strangely the Convert.ToInt32 doesn't strip the comma and return a number but the ToDecimal function does.
Is there some way I can flag it as a string value to prevent Editor from trying to convert it at all?
As a quick work around - because I don't use Decimals very much I've decided commas in a decimal are invalid and I'm not returning a valid decimal if I receive
1,00.25. I'll put some extra coding around any decimals where I do need commas as required.
What does it save
1,3
as? I presume your above comment relates to1.3
?Currently no - you'd need to remove that code from the library I'm afraid.
Thanks,
Allan