Bug - decimal places get not stored in MySQL at STRATO

Scriptcase 9 Bugs
#1

Absolute no decimal places get not stored in MySQL at the provider STRATO.

I have PHP 7.3 at my Windows development PC and at STRATO as well.
On MySQL in my Windows development PC decimal places get stored.

Same objects online at STRATO do not work proper with decimal places. I get always zero after the dot.
I use in SC 9.4.031 the regional settings for currency. This is a comma in Germany. But I tested with dot as well. Dot or comma do not make any difference - no decimal place get stored in my online application at STRATO.

#2

Hard to say what’s wrong using this description.

My best guess is to check the settings for decimal character in the connection.

Gunter Eibl

#3

Thank you!
Do you mean database “connection”?
I have nothing changed there and all was running fine at STRATO until end of last year before SC has send us all a big update. We had to generate all and had to deploy to production.

Viele GrĂĽĂźe aus Berlin!

#4

I had a similar issue quite some time ago, don’t recall the details, but the bug (and it was a bug) was actually in MySQL Workbench.

#5

Yes, I mentioned the database connection :wink:

And you’re right that there have been several issues with that SC update, but none of my customers or me myself had problem with decimals and the database :confused:

Therefore I only can guess from here without knowing your project.

Sonnige GrĂĽĂźe aus MĂĽnchen!

Gunter Eibl

#6

Thanks for the replay.
The DB development with MySQL Workbench has been finished since long time. I guess that most SC user run there productive online application on an environment where there have admin right for the OS. This makes a different to cause an error or not. SC is not more a pure PHP generator.
An example is PDF generation with SC. For that you have to have admin right of the OS to configure things. On my dev machine I have of course no problems with PDF generation. My online application is at a big provider. All has worked fine until end of last year. So I think to restore the online application from that time and denial any update offer from SC.

#7

Thanks!

  1. I guess you and your customer have a new licence with all updates.
  2. I guess you and your customer have on the productive machine for the online application with admin rights. What this has to do with the problem? I can tell you what is not working generated with SC (0172-6975451) and has an impact!
  3. I have an old licence but with all new SC updates where some areas are blocked. Fine! I don’t need!
  4. SC is not anymore a pure PHP generator. They ask for OS to deploy. Why? Not needed for a deployment to a pure PHP runtime engine. In past SC never ask.
  5. I think I will ask STRATO for a backup of PHP files from December last year before SC 9.4 was released. I will also ask SC sales about the release plans this and last year. (Btw. on my Windows dev mashine I have no decimal places problems.)

For you it could sound wired.

SC should go back to be a pure PHP file generator independend from any OS!

#8

Workbench has been finished for a long long time; that was my thought too. But after extensive testing (and this was just a year ago) it IS workbench that has the issue with decimals. As for PDF generation from the grid; yes I agree. mkhtmltopdf doesn’t work well with scriptcase (that’s the library they are using to print pdf from grid). It works fine on the local box but I haven’t been able to make it work when I am connected (even in development) on the web. I have, however, had success - on both local and the web - with PDF reports (which uses a different program) although I find those cumbersome to build; the print from grid would be much nicer because the grid allows me to create my own html… Hoping they figure it out (or I do). Have to have PDF in this day and age; but I haven’t decided yet to toss it out in the yard. There are things that I like about sc. Maybe I should make a list.

1 Like
#9

I agree. I would like to see it be OS independent (and with the PDF issue it is apparently not; do it one way on windows and another on linux and set permissions … ugh … it would also be nice if it was in english for me … might as well do the hard coding and forget the ide. There is another that I have been keeping my eye on; looks promising but I would lose some of the functionality that SC provides.

1 Like
#10

With the Smartphone App (using the online PHP files) I cannot make any currency tranfer anymore.
It was a horror at a demonstration at a customer. I stopped any sales.
So a restore of PHP files (before SC 9.4 was released) is the fastes solution I guess.

#11

Hi Klaus,

“I guess you and your customer have a new licence with all updates.”
NO. In fact I myself have both, old and new version on different SC development servers.
I do need this to be compatible with all customers…

"I guess you and your customer have on the productive machine for the online application with admin rights. "
Most of them but not all.

“I have an old licence but with all new SC updates where some areas are blocked. Fine! I don’t need!”
Correct, BUT on the development server none has made updates after the release of the new SC version. We clearly stick on the old version.

" SC is not anymore a pure PHP generator. They ask for OS to deploy. Why? Not needed for a deployment to a pure PHP runtime engine. In past SC never ask."
There are several issues why they ask for the deployment system. For example one is the rights managment which different between Windows and Linux. Another is the version of some libraries to use on the target OS.
Over all I understand and appreciate them for asking and trying to adopt the deploment. Maybe their current solution is not perfect…

Workbench could be replaced by HeidiSQL, which is used by a lot of developers.

#12

HeidiSQL is what I am using since finding the bug in workbench.

#13

if you have just one format specified, that format is used for display and data entry. with a currency format, this means you need to input the currency symbol in addition to your numbers.

you can specify separate display and data entry formats by using the pipe symbol. a format of “$#,###,###.00|#” allows you to enter just numbers that will be displayed in currency.

also note that with mysql you do not want to use the float data type for storing currency as this is an approximate numeric storage type. use the exact numeric: decimal(19,2). if you create a number column with a length of 2 using servoy’s dataprovider you will get this number type. if you don’t specify a length, you will get the float number type. mysql backend specific tips only – not sure about all the numeric types in sybase.

1 Like
#14

Great!
I have done a workaround that I update only the decimal fields again after the event of normal update. This looks a bit strange but it works.