Can someone tell me why Servoy creates for numeric fields:
doubles and sometimes :
numeric size(19) scale(8)
We use Sybase Ianywere 9 and we create all tables & columns inside Servoy.
What is the difference between them, and why does Servoy use both?
Something similar was reported on another thread:
http://forum.servoy.com/viewtopic.php?p=36976#36976
issue??
kazar
hmmm, indeed.
I hope some one of Servoy can clarify this…
Are you experiencing any particular issues because of this or do you just want to spend some time talking about the different ways in pronouncing the word float?
yes, we had some issues. some updates where complaining that the column allready existed as double, and the import contains numeric.
Because we only use Servoy to add tables and columns I find it strange, why Servoy uses mostly double for numeric fields and sometimes numeric. (i’m talking about iAnywhere in this case.)
so, that’s how I came to this question.
I also looked into the UDM database of Servoy (Servoy CRM) and there I see the same. for the quantity (in the orderlines) you are using (in Sybase) numeric fields and, for example, the unityprice a double.
So what is the reason, for that?
Can you be more specific: in your post I don’t see a specific list of things that did not work or errors or logfiles, etc.
Hi Jan,
jaleman:
Can you be more specific: in your post I don’t see a specific list of things that did not work or errors or logfiles, etc.
If I read your posts correctly, and I think I do, you are saying “hey it works, so why the fuzz”. Which I can understand from your point of view.
But first of all Harjo doesn’t say it doesn’t work or else his post would be in Issues and Bugs, not to mention the bugbase. What he says is that Servoy doesn’t act consistently, even on the same version of database backend. So that raises questions.
And apparently Harjo is not the only one that came to that conclusion.
So hopefully you can shet some light on this. Or maybe someone else at Servoy can.
Hi Robert, you understood it right.
Jan, am I that unclear?
jaleman:
Can you be more specific: in your post I don’t see a specific list of things that did not work or errors or logfiles, etc.
No indeed, everything just works, I just ignored the messages.
After that I did some investigation on this, and saw what I describe above.
So i’m not sure if it as a bug or issue or whatever.
I just wanted to know, why Servoy uses sometimes doubles and sometimes numeric fields, when we add a new numeric field inside Servoy.
I hope this clears it more…
ROCLASI:
Hi Jan,jaleman:
Can you be more specific: in your post I don’t see a specific list of things that did not work or errors or logfiles, etc.If I read your posts correctly, and I think I do, you are saying “hey it works, so why the fuzz”.
No that was not my point, I just didn’t get the question and actually I still don’t. Float’s, numerics and doubles are all very closely related and I’m happy to talk about it in detail but I’m afraid the confusion will only get bigger if we first not discuss what the question is. So let’s take a step back and first talk about what exactly the concern is and how this is affecting your solutions, also lets all go back to the documentation of your favourite database and do some reading on the different numeric datatypes. Then lets do some reading on the Java datatypes and some JDBC reading on how types map from SQL to Java through JDBC and then when we’re all on the same page lets have a tech discussion while all speaking the same language.
Just to avoid further confusion while you guys start reading some background info about databases, Java and JDBC drivers: Servoy always uses doubles. Hibernate and JDBC drivers, depending on version and vendor might map this to a type that is named differently in a database but will offer the same functionality. At least that is the idea, if it doesn’t please inform us ASAP.
Hi Jan,
jaleman:
Just to avoid further confusion while you guys start reading some background info about databases, Java and JDBC drivers: Servoy always uses doubles. Hibernate and JDBC drivers, depending on version and vendor might map this to a type that is named differently in a database but will offer the same functionality. At least that is the idea, if it doesn’t please inform us ASAP.
Thank you for this answer.
This gives us some insight in what the product Servoy does or should do. It definitely gives us more handles of providing you with the information you might need to fix any issue that might be present here.
Like most of the developers here we choose Servoy to NOT dig into the bowels of all things Java/JDBC/take-your-pick but to be more productive in getting solutions done.
In other words beating that Mythical Man-Month that Peter S. Kastner of the Aberdeen Group talked about in his keynote speech at ServoyWorld 2006.
So again, thank you and a Merry Christmas!
oke, will try to create a sample/reproducable-case than.
I have seen a few times, that columns becomes numeric in Sybase iAnywhere when we imported our solution into a new Servoy server.
And I’m sure every column was created in Servoy. (in my developer)
The second time we import a new version of our solution to that server, Servoy complains about the differences of those columns.
jaleman:
Just to avoid further confusion while you guys start reading some background info about databases, Java and JDBC drivers: Servoy always uses doubles. Hibernate and JDBC drivers, depending on version and vendor might map this to a type that is named differently in a database but will offer the same functionality. At least that is the idea, if it doesn’t please inform us ASAP.
Hi Jan –
In the thread I linked to above http://forum.servoy.com/viewtopic.php?p=36976#36976 , Rodney Sierberhausen reports that he is seeing Servoy create different numeric types on a different server, with MySQL, Servoy and the drivers all being the same version. I think this is the part that gets a bit unnerving … not that any behavioral problem is observed in the solution, but the reports of (the perceived) randomness of column types created.
Perhaps Rodney could confirm that he has triple-checked that MySQL, JDBC driver, and Servoy versions are indeed exactly the same on both boxes. Is there anything else that might cause the issue?
thanks, Jan,
kazar
kazar:
jaleman:
Just to avoid further confusion while you guys start reading some background info about databases, Java and JDBC drivers: Servoy always uses doubles. Hibernate and JDBC drivers, depending on version and vendor might map this to a type that is named differently in a database but will offer the same functionality. At least that is the idea, if it doesn’t please inform us ASAP.Hi Jan –
In the thread I linked to above http://forum.servoy.com/viewtopic.php?p=36976#36976 , Rodney Sierberhausen reports that he is seeing Servoy create different numeric types on a different server, with MySQL, Servoy and the drivers all being the same version. I think this is the part that gets a bit unnerving … not that any behavioral problem is observed in the solution, but the reports of (the perceived) randomness of column types created.
Perhaps Rodney could confirm that he has triple-checked that MySQL, JDBC driver, and Servoy versions are indeed exactly the same on both boxes. Is there anything else that might cause the issue?
thanks, Jan,
kazar
I have seen mysql 5.x do very funny things with JDBC doubles. But again as I have mentioned before please post something specific and lets not talke about ‘unnerving’ until we have something ‘unnerving’ going on.
Our rules of thumb using MySQL 5.024, the latest JDBC driver and Servoy:
1- the default number field type that servoy creates is float. however, float is the most limited number type in terms of usefulness as it only stores 3 spots to the right of the decimal point. use the double type instead for approximate numeric values (you will have to change in the backend manually).
2- it is easy to forget that servoy has a default mask on number fields that limits the display to two decimal places unless you specify your own format. this default mask does not limit how many decimal places are stored in the backend. this perceived discrepancy can lead to much confusion when you start doing math.
3- currency: you need to use the decimal type here with the precision set to two. do not use float or numeric for currency! they are imprecise numeric types and you will accumulate a small amount of error over the course of many aggregations.
you can create a decimal type in servoy by creating a number field with a length of two. in the backend a field of type “decimal(19,2)” is created.
4- if your solution has a lot of number type fields, do not rely solely on servoy’s data designer. you really need to know your database’s specific characteristics.
5- *** do not rely on servoy to rebuild your correct data structure when you do a clean import of a solution. if you specify things using a backend tool it is highly likely that servoy will not bring over those changes.
to preserve data types, etc always do a structure dump of your backend and restore that to rebuild somewhere else. then import your servoy solution and ignore all data type “error” messages as servoy will not overwrite a column type that is already there.
Hi
This situation is really getting worse for me.
In my development system when i create number fields in servoy it will default to float type in the mySQL backend. I check these and make sure they are all float before i export the solution.
When i export this file and import clean via the servoy admin tool into an empty database it changes all the float fields to decimal type fields (19,0). I then have to change these back using back end tools to float or double type fields. This is of course unnerving for a vertical market situation especially when i am posting regular updates (monthly) which may contain new number fields.
Of course when they import a solution file they get a large number of warnings regarding the differences in field types. If i change all the fields to floats all the warnings on import are gone.
I am very careful of versions for my installations. MySQL 5.027, JDBC 1.5.06 and Servoy 2.25 all exactly same versions.
I have just done another installation today exactly the same behaviour. Floats become decimal (19,0) on solution import.
Would like someone to shed some light on why floats convert to decimal (19,0) on import and how i can stop this? Maybe use Double type?
Hi
I should note that once a number field has been imported and changed to float type using back end tools. A new solution import will not change these only new number fields will be decimal (19,0) from a new import/version.
Does this occurr on iAnywhere too or just mysql? Any specific reason why you are using mysql for a vertical? Bundling mysql in a vertical solution is much more expensive than iAnywhere.
Rodney,
I suggest you don’t let Servoy create the tables/columns.
It is wise to use you own data modeling SQL for this for a number of reasons.
Let me name a few:
Hope this helps.
Hi
Only tested on mySQL, Using this for the repository_server and solution data.
Community version.