I posted this message against the server forum with no response, so now i am trying here)
I have a solution working fine locally, but after i deploy onto my hosted server the solution is not working properly in the client. Even after i have flushed both the solution and the client data cache.
The problem is i have some calculations, like order total, tax etc, which are not calculating properly.
I have also done a clean import, then exported this to the hosted server, with the same problem occuring.
Can you give us some more information?
Like what backend database. Do you use the same version/brand database on the server. What about jdbc driver versions (developer/server). What java versions.
Also what do you mean specifically with ‘not calculating properly’.
P.s. this forum allows you to edit your post after you submitted it. No need to post a new message. (you can delete your old one too)
Hi again
I can see now what is happening to the calculation.
Instead of adding 2 amounts the values are being concatenated together.
Var price = min_price + next_price
Example: 60 + 200
In Developer = 260
In Hosted system = 60,200
I guess i need to delete the solution on the hosted system and reimport.
However i am using a hosted system on Linux, which i don’t know at all.
The hosting company installed Servoy for me, and i just load solutions onto the server via the server admin page.
It would be really usefull to delete solutions via the server admin page.
If you can import why not allow a solution to be removed as well without having to login to the machine and run Servoy Developer?
If the admin person who logs on has a developer key then this should be allowed.
ROCLASI:
Hi Marcus,
Can you give us some more information?
Like what backend database. Do you use the same version/brand database on the server. What about jdbc driver versions (developer/server). What java versions.
Also what do you mean specifically with ‘not calculating properly’.
P.s. this forum allows you to edit your post after you submitted it. No need to post a new message. (you can delete your old one too)
You don’t have to delete your solution to get the fix to the users. Just upload the new release and let the users re-login and they will be using the fixed version.
But indeed there are situations where you want to be able to delete a solution. But also keep in mind that there are installations where not only the administrator is accessing these pages. So far there is no fine grained permission scheme for these pages so it’s pretty much all or nothing.
That might well be the reason why we don’t have a delete function.
an import of a “clean import” of the same solution
Nothing seems to work.
Did you look at the solution i sent you?
Look at the orders_subtotal calculation for frm_orders.
The price variable calcualtion is being concatenated, not added as it should.
var min_price
var rem_mass
var next_price
var price
if(orders_to_order_items)
{
if(orders_to_order_items.chargeable_mass && rate_id)
{
if (orders_rate_id_to_rates.min_kg && orders_rate_id_to_rates.min_price)
{
if (orders_to_order_items.chargeable_mass > orders_rate_id_to_rates.min_kg)
{
//min_price = orders_rate_id_to_rates.min_price
rem_mass = orders_to_order_items.chargeable_mass - orders_rate_id_to_rates.min_kg
next_price = orders_rate_id_to_rates.next_price * (rem_mass / orders_rate_id_to_rates.next_kg)
price = orders_rate_id_to_rates.min_price + next_price
return price
}
else
{
return orders_rate_id_to_rates.min_price
}
}
}
}
else
{
return 0
}
Interesting to see you declare variables without giving them a value. I.e they don’t know yet what type they are.
What happens if you change the following line of code:price = orders_rate_id_to_rates.min_price + next_price to this: ```
price = Number(orders_rate_id_to_rates.min_price) + Number(next_price)
This will cast those values to numbers and the adding up should work correctly.
Hope this helps.
Robert, isn’t this more of a remedy instead of a cure.
Type casting should not be necessary unless the types are wrong…
When types are wrong they should be changed imho…
Or do I miss something crucial (very well possible with the hangover I have right now)…
Marcel, it’s indeed treating the symptoms instead of the cause.
Marcus, when I import your solution I get the following messages. Indeed the exact tables that give you issues.
The server version of the column 'quantity' of table 'order_items' in server 'udm' has length 0 while in the import version the column has length 7.
The server version of the column 'mass' of table 'order_items' in server 'udm' has length 0 while in the import version the column has length 5.
The server version of the column 'chargeable_mass' of table 'order_items' in server 'udm' has length 0 while in the import version the column has length 6.
The server version of the column 'documentation' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 4.
The server version of the column 'volumetric' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 6.
The server version of the column 'next_price' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 6.
The server version of the column 'fuel_surcharge' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 4.
The server version of the column 'min_price' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 6.
The server version of the column 'min_kg' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 2.
The server version of the column 'next_kg' of table 'rates' in server 'udm' has length 0 while in the import version the column has length 2.
It’s hard to test things for me because the order screen gives me loads of errors that are most likely related to this.
I suggest you check your backend tables (using a third party tool) and compare them with what Servoy thinks they are.
If they differ then this might as well be a jdbc driver issue.
EDIT: nevermind. This looks like it’s an issue on my side. Servoy didn’t create the tables correctly during import.
Hi Marcel
I am using existing tables as well as custom.
The dataproviders in question are all numeric.
I am using the UDM database tables and adding new fields where needed.
Thanks for the help
IT2Be:
Are you sure both values are of number (or whatever) type and not string?
It looks like one of the two is some sort of string type…
Have you installed your release over existing tables that caused this?
From the error Robert posted I would say your export contains columns with lengths that differ from the original. Although length 0 doesn’t make sense.
Whatever it is there is something wrong with the database or the driver I would say.
If I were you I would follow Robert’s suggestion, it is the best you can do…
I dropped the database and recreated it again. Reimported the solution from Marcus again and still get this table:
Table "public.order_items"
Column | Type | Modifiers
-------------------+-----------------------------+-----------
quantity | numeric |
order_id | integer |
orderitem_id | integer | not null
chargeable_mass | numeric |
product_id | integer |
modification_date | timestamp without time zone |
d_width | character varying(5) |
price_each | double precision |
creation_date | timestamp without time zone |
cost_each | double precision |
mass | numeric |
modification_user | integer |
d_lenth | character varying(5) |
extended_price | double precision |
description | character varying(1500) |
creation_user | integer |
d_height | character varying(5) |
Indexes:
"order_items_pkey" PRIMARY KEY, btree (orderitem_id)
Notice the Numeric fields…they have no length.
Servoy Developer
Version 3.1.6-build 410
Java version 1.5.0_07-87 (Mac OS X)
JDBC Driver 8.2-505.jdbc3 (latest version)
PostgreSQL 8.2.4 on i386-apple-darwin8.9.1, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Very odd.
Then again I tend to create the tables myself before I import a solution. Mostly because I use foreign key constraints, database sequences, indexes, etc. that Servoy will never create for me.
So that might be the reason I never saw this before.
Hi Robert
I went to the database layer with sysbase central and saw that some of the fields involved in the calculation were varchar, and others numeric with much longer length than defined in the table view for dataproviders in Servoy.
What i have done before is delete a field in Servoy and then recreate the field again with a different type and/or length.
Perhaps if changes are made on the servoy level after the initial drop of the tables, then servoy does not update the data layer properly for changes to individual fields.
I will test this to see if this is a problem.
Regards
Marcus
ROCLASI:
I dropped the database and recreated it again. Reimported the solution from Marcus again and still get this table:
Table "public.order_items"
Column | Type | Modifiers
-------------------±----------------------------±----------
quantity | numeric |
order_id | integer |
orderitem_id | integer | not null
chargeable_mass | numeric |
product_id | integer |
modification_date | timestamp without time zone |
d_width | character varying(5) |
price_each | double precision |
creation_date | timestamp without time zone |
cost_each | double precision |
mass | numeric |
modification_user | integer |
d_lenth | character varying(5) |
extended_price | double precision |
description | character varying(1500) |
creation_user | integer |
d_height | character varying(5) |
Indexes:
“order_items_pkey” PRIMARY KEY, btree (orderitem_id)
Notice the Numeric fields...they have no length.
Servoy Developer
Version 3.1.6-build 410
Java version 1.5.0_07-87 (Mac OS X)
JDBC Driver 8.2-505.jdbc3 (latest version)
PostgreSQL 8.2.4 on i386-apple-darwin8.9.1, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Very odd.
Then again I tend to create the tables myself before I import a solution. Mostly because I use foreign key constraints, database sequences, indexes, etc. that Servoy will never create for me.
So that might be the reason I never saw this before.