Different behaviour - Web vs local

[billkay]

Hello,

(I've tried a number of different search strings on this forum, no idea what the words are to search for what I believe is some sort of bug), so I'll explain what the problem is, and hopefully this was solved/talked about somewhere.

I've got a fully functional A5W website, and things seem to be working perfectly fine when running from the LOCAL platinum server. I am using a grid with detail view, and the detail has a variety of "numeric" fields that can be updated.
I can update the fields easily, along with text boxes etc... everything works fine.

However, when I publish the files to the remote server, and run the same files, and the same data, (I copied them back and forth to make sure), after I click SUBMIT, (and the record gets posted back, even WITHOUT CHANGING ANY of the data on the detail view), and when the grid loads again, ALL numeric fields get TRUNCATED... i.e. $24,000 gets converted to $24, $1,300 gets chopped to $1

I've performed a complete publish with ALL files to the remote server, and still the localhost behaves properly, and the remote application server truncates the data.

Seems it only happens with any values over 1,000. (999 doesn't get truncated.)

If it was something I've done, then wouldn't it behave the same on each server?

Obviously this is driving me nuts, as I have no idea why this is happening, or how to debug it! Could this be a bug? OR is there something I could have done?

Thanks!

[Steve Wood]

Re: Different behaviour - Web vs local

Determine what the table values are both before and after you submit your grid. Do they start out 24000 and end up 24 after submit, or some thing else? You put quotes around the word "numeric". It is a numeric field type or something else? Is there a calculation on the field in Field Rules? What is your grid property for Size and MaxLengh set to? You show $ in your example, so what is the Display Format for the field? Or is the $ actually in the tables stored value? You said you copy data back and forth, do you PUBLISH the database? And if you do manually copy files, do you include ALL files related to the table, or just the DBF file?

[billkay]

Re: Different behaviour - Web vs local

Thanks Steve,

Ok...
The fields effected are NUMERIC, with 8 width, and 0 decimal.
If I manually input 24000 into the detail view and click SUBMIT, all updates as expected, and $24,000 is displayed in the grid view.
IF I click the detail view link again, to display the detail view, still displays correctly, however If I press SUBMIT (even without altering anything on the detail view), the (now $24,000) gets changed to $24 when the grid comes up.
Yes, I am using the publish features (I manually copied all dbf, fpt, ddm, ddd, ddx files from live server back to local, made adjustments (like made all numeric fields the same lengths (now 8), then copied them back to the remote).

Yes, the data in the table appears as it is displayed in the form. There are no transformations in the database tables. It seems that the conversion happens upon SUBMIT.

Seems for some reason, when the value is displayed in an editable field (text box) as $24,000, when submit is pressed, Alpha barfs at the "," and drops it. It then stores 24 in the database.

When the data is called it displays $24

I'm thinking the problem is the alltrim(str(<value>,250,0,"$(")) that I have on each and every field "Display format" (even the textboxes in detail view), but this should only effect what is being displayed, and not what is stored? no?

When the data gets posted back to the database, I would expect the $ and the , to be stripped, leaving 24000 to be posted, but it doesn't, it instead truncates everything after the ,. Any number 999 and under is not effected (I guess because there is no comma!?).

Funny... it was working perfectly in a previous version, and only now has it broken when I did the latest update.

Thanks Steve for any other ideas!
Bill

[Peter.Greulich]

Re: Different behaviour - Web vs local

Not sure, but try:

alltrim(str(<value>,250,2,"$("))


BTW: "250"? Seems like overkill, no?

[Steve Wood]

Re: Different behaviour - Web vs local

Seems to work even if I put 2500 in the length field, but yes I would agree that parameter should be no bigger than what the table field will actually hold.

Are you sure the fields are Numeric, and not perhaps NumericExponent type? I have no problem in my test, using your display format in grid or detail. But I do get that problem if I change to numericexponent type.

How about attaching your grid here for us to test.

[mmaisterrena]

Re: Different behaviour - Web vs local

What happens if you put a value without comas? ej. 24000
does this gets truncated too?

[billkay]

Re: Different behaviour - Web vs local

OK, ran a few more tests...

If I go without commas, it gets stored properly only on the FIRST SUBMIT, then when it gets redisplayed, I get $24,0000 (as expected), but then when I click to editable grid and click submit it gets truncated again before posting to datatable.

(The 250,0 was just the default that the "wizard" inserted... I've since changed it to 8,0 and 10,0 (and even tried 10,2) to no avail. I don't wan't/need cents)

Table particulars:
NUMERIC data type.
Width = 10 (Was 6, I've increased it just in case)
decimal=0 (I don't need cents)

This does not work...
Setup in Gridview, and has link to detail view where editable:
Grid view
Field Display format = alltrim(str(<value>,10,0,"$("))
Detail View
Field Display format = alltrim(str(<value>,10,0,"$(")) (this is an editable text box)

Once SUBMIT is pressed, (even if nothing changed) (BTW, maybe the system THINKS something is changed.?.. as the data in the table says 24000, but $24,000 is DISPLAYED in the editable text box. Once submit is pressed... I check the table and it contains 24

There are no transforms in the table

If I remove all Field Display Formatting, BOTH in the grid and the detail view editable text box, then everything works fine, however, of course everything is displayed without formatting.

Strangely, I would expect that as a minimum it would allow me to at least display the grid values with alltrim(str(<value>,10,0,"$(")). If I click the detail view link, it still pulls in the formatting from the grid view, even though none was specified for the text box in the detail view.

Maybe the best question to ask now would be, "What is the proper setup to be able to store a currency in a table, where the currency is stored as a whole number, and is displayed in the grid as a $nn,nnn, and also in the editable grid portion as $nn,nnnn, but will allow a user to input nnnnn into the field, and store it properly. Should I even be THINKING I should be able to display the currency in an editable text box (detail view) like $24,000?? I would expect it to be possible, then when posting, Alpha should strip the formatting off it, before posting to the database table. Maybe I'm wrong.

It is most definitely something to do with the alltrim(str(<value>,10,0,"$(")) display format and where/when to use it. Maybe my ideas of what I'm expecting of Alpha5 is out of line.

Thank again for any tips... If no ideas, I can post the component, for your review. It's a biggie...

[Steve Wood]

Re: Different behaviour - Web vs local

One obscure thought, and I did not test this, in Numerics the "0" is the same as a null. If you alltrim() what is, or was (before the str()) a numeric 0, would that strip it off? This doesn't sound plausable but I will press the Reply button anyway.

[billkay]

Re: Different behaviour - Web vs local

Ok... another discovery...

I've removed ALL formatting, in both grid view and detail view.

If in the detail view I put in a $24,000 and click submit, it gets truncated to 24.

$24000 (without comma) is accepted properly!!

It is most definitely the COMMA!

I would have expected an "error" of some type, but instead, it accepted it and just truncated it.

Thus, I would presume that when the COMMA is added to the display format in the EDITABLE text box, the editable grid sees this as a CHANGE in the data and attempts to post it back, where the system (somewhere) truncates it at the comma

Again, I am positive that this was functioning properly in a previous minor release (2 weeks ago?), only now it is truncating.

I'm just blindly using the "Select Pre-Defined Format".

Thanks again!

[Pat Bremkamp]

Re: Different behaviour - Web vs local

There is a place in the settings where you can tell Alpha what the character is for decimal point. Sounds like yours is set to comma instead of period.

Pat

[billkay]

Re: Different behaviour - Web vs local

Thanks Pat,

If you can point out where that is, I'd love to give that a try.

Thanks,
Bill

[Pat Bremkamp]

Re: Different behaviour - Web vs local

Bill,

Sorry, it was in the field validation instead of settings. If you click on validation for a numeric field and if you set the numeric type to fixed or variable decimal, then you can see the choice. You can't see it for integers.

Pat

[billkay]

Re: Different behaviour - Web vs local

Thanks everyone...

I've been PM'd with the solution... thought I'd share...

Put

strtran(<value>,",","")

in the field UNformat. This way Alpha doesn't get confused with the commas being passed back.

All works proper now, but I'm convinced it all USED to work. hmmmm.... ;)

Thanks!

[ColinJD]

Re: Different behaviour - Web vs local

I have seen something similar to this somewhere else.
In some parts of the world apparently 1,234.56 can be written as 1.234,56
thus this problem could indeed be in Windows, and possibly the LOCALE of your server is different to that of your development machine.
Just a thought.

[mmaisterrena]

Re: Different behaviour - Web vs local

Yes Bill that used to work i think , I got the same error a couple of months ago and I decided to tel the user to feed numbers unformated not allowing special characters in the validation rules and displaying the field without format, Im glad you found a work arround

By the way this problem only occurs in dialogs and not in grids (in my case)