what a day. I try to insert a edited picture field into a postgres db and it doesnt want to take my WS-AMT FIELD. It truncates the 2 decimal places and replaces them with zeros. It is weird because the edited field is correct. So like if i go to insert 8.24 i get in postgresql 8.00 in my db table.
The postgres table is decimal (10,2).
I also in another issue can't get accept to take the field from my screen item it wants to have me input it again in the upper left corner of my window. That is kind of weird because it is alreay my screen.
Like this - Accept WS-AMOUNT.
I don't know why i have to use something like this...
move function numval(WS-AMOUNT) to Field9 WS-AMT
but it seemed to work really cool, however.
thanks for any assistance,
jim
Sent with Proton Mail secure email.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what a day. I try to insert a edited picture field into a postgres db
and it doesnt want to take my WS-AMT FIELD. It truncates the 2 decimal
places and replaces them with zeros. It is weird because the edited
field is correct. So like if i go to insert 8.24 i get in postgresql
8.00 in my db table.
The postgres table is decimal (10,2).
I also in another issue can't get accept to take the field from my
screen item it wants to have me input it again in the upper left
corner of my window. That is kind of weird because it is alreay my screen.
Like this - Accept WS-AMOUNT.
I don't know why i have to use something like this...
move function numval(WS-AMOUNT) to Field9 WS-AMT
but it seemed to work really cool, however.
I read in the example docs you are storing in comp-3.
So I guess this is to retain decimal and not do binary where you have to
divide by a number to get the decimal back.
Chatgpt said if it is in binary pic S9(13)v99 or such that it loses the decimal.
I didnt see you directly insert a parameter into INSERT like this :WS-AMOUNT
but I think that is probably it, that I didn't use comp-3 for the insert into postgres.
I saw in insert statements where you were using hard coded INSERT into emp_tbl (payrate) values (20.13) but not like INSERT into emp_tbl (payrate) values (:WS-PAYRATE) WHERE
working storage was populated from a value stored with a pic clause like this PIC S9(13)V99 COMP-3 VALUE 0.
I will check out later. I think this was the issue!
sorry the problem resolved itself with one try. I tried to write back.
The problem was comp-3. Otherwise, postgresql didn't accept it with a decimal.
I will read your thread carefully for reference but i fixed it simply by changing to comp-3 to retain the decimal.
It is very cool that you have an accounting project in COBOL. i know a little debit and credit and think it is very neat that you can do that in a programming language. I still have a lot to learn, and am hopeful that I have the opportunity to do it.
Have the coolest of holidays and thanks for reaching out to me.
The accounting people have to stick together. AI is literally displacing some accounting people. Those who know tech are in the best place to stop that from happening possibly.
I had an idea for accounting that A-L=OE and each account code had a class associated with it and i could use triggers and procedures to keep it in balance based on a sequence number but I know so little COBOL and postgresql that I struggle to implement it because what is simple for you guys is not for me. Think about that Exp class 4 is negative equity and REV class 5 is positive equity and you know the others you can see if you know the classification system and the effects on equity how easy it is to create the reconciler. But it takes experience like yours.
Interesting choice of database. I dropped learning firebird because if a lock or transaction goes kooky too hard to decipher from system internals for me. Everything is tied to the transaction id and if it is in a funk you need to be a db scientist to figure it out.
Then select cvs-3.02 and then pick the "svn checkout" box (assuming you
have svn installed) to get the current version.
Note that this area can be updated almost daily as I am in the middle of
testing.
All manuals are included along with the LibreOffice writer sources in
ODF format.
I welcome help in testing and manual updating as all work is just me now
and it is a lot for one person and more so now that I will be 78 next June.
This was a commercial package until I migrated the entire system from
Micro Focus Cobol (very expensive paid version) to GnuCobol.
GnuCobol version used is v3.2 final as all others can be flaky, at least
as far as my testing shows.
On 22/12/2024 13:41, J McNamara wrote:
Vincent,
sorry the problem resolved itself with one try. I tried to write back.
The problem was comp-3. Otherwise, postgresql didn't accept it with a
decimal.
I will read your thread carefully for reference but i fixed it simply
by changing to comp-3 to retain the decimal.
It is very cool that you have an accounting project in COBOL. i know a
little debit and credit and think it is very neat that you can do that
in a programming language. I still have a lot to learn, and am hopeful
that I have the opportunity to do it.
Have the coolest of holidays and thanks for reaching out to me.
The accounting people have to stick together. AI is literally
displacing some accounting people. Those who know tech are in the best
place to stop that from happening possibly.
I had an idea for accounting that A-L=OE and each account code had a
class associated with it and i could use triggers and procedures to
keep it in balance based on a sequence number but I know so little
COBOL and postgresql that I struggle to implement it because what is
simple for you guys is not for me. Think about that Exp class 4 is
negative equity and REV class 5 is positive equity and you know the
others you can see if you know the classification system and the
effects on equity how easy it is to create the reconciler. But it
takes experience like yours.
Interesting choice of database. I dropped learning firebird because if
a lock or transaction goes kooky too hard to decipher from system
internals for me. Everything is tied to the transaction id and if it
is in a funk you need to be a db scientist to figure it out.
I will look into checking it out. This is very cool to look at. But it will take me a bit to get to it as I am in the middle of a few things at once.
That is very cool you are on your way to 78..
Lord willing you will make it and then some. I am getting up there very close to senior. AARP wants to talk to me, but I am in hiding.
I know people in their early 70s and they are kind of spry for their age.
Its only a number.
Thanks for the opportunity to check out and interact with your cool software. I am especially interested in seeing navigation and menu systems and screen layouts.
Then select cvs-3.02 and then pick the "svn checkout" box (assuming you
have svn installed) to get the current version.
Note that this area can be updated almost daily as I am in the middle of
testing.
All manuals are included along with the LibreOffice writer sources in
ODF format.
I welcome help in testing and manual updating as all work is just me now
and it is a lot for one person and more so now that I will be 78 next June.
This was a commercial package until I migrated the entire system from
Micro Focus Cobol (very expensive paid version) to GnuCobol.
GnuCobol version used is v3.2 final as all others can be flaky, at least
as far as my testing shows.
On 22/12/2024 13:41, J McNamara wrote:
Vincent,
sorry the problem resolved itself with one try. I tried to write back.
The problem was comp-3. Otherwise, postgresql didn't accept it with a
decimal.
I will read your thread carefully for reference but i fixed it simply
by changing to comp-3 to retain the decimal.
It is very cool that you have an accounting project in COBOL. i know a
little debit and credit and think it is very neat that you can do that
in a programming language. I still have a lot to learn, and am hopeful
that I have the opportunity to do it.
Have the coolest of holidays and thanks for reaching out to me.
The accounting people have to stick together. AI is literally
displacing some accounting people. Those who know tech are in the best
place to stop that from happening possibly.
I had an idea for accounting that A-L=OE and each account code had a
class associated with it and i could use triggers and procedures to
keep it in balance based on a sequence number but I know so little
COBOL and postgresql that I struggle to implement it because what is
simple for you guys is not for me. Think about that Exp class 4 is
negative equity and REV class 5 is positive equity and you know the
others you can see if you know the classification system and the
effects on equity how easy it is to create the reconciler. But it
takes experience like yours.
Interesting choice of database. I dropped learning firebird because if
a lock or transaction goes kooky too hard to decipher from system
internals for me. Everything is tied to the transaction id and if it
is in a funk you need to be a db scientist to figure it out.
EXEC SQL
INSERT INTO "my_table"
( "id", "amount", "trans_type", "trans_date", "gl_acct",
"class_value", "seq_num")
VALUES ( DEFAULT, :WS-AMT, TRIM(:WS-TRANS-TYPE),
TO_DATE(:WS-TRANS-DATE, 'YYYY-MM-DD'),
TRIM(:WS-GL-ACCOUNT),
:WS-CLASS-VALUE,
:WS-SEQ-ID)
END-EXEC
Hi all,
what a day. I try to insert a edited picture field into a postgres db and it doesnt want to take my WS-AMT FIELD. It truncates the 2 decimal places and replaces them with zeros. It is weird because the edited field is correct. So like if i go to insert 8.24 i get in postgresql 8.00 in my db table.
The postgres table is decimal (10,2).
I also in another issue can't get accept to take the field from my screen item it wants to have me input it again in the upper left corner of my window. That is kind of weird because it is alreay my screen.
Like this - Accept WS-AMOUNT.
I don't know why i have to use something like this...
move function numval(WS-AMOUNT) to Field9 WS-AMT
but it seemed to work really cool, however.
thanks for any assistance,
jim
Sent with Proton Mail secure email.
Use simple numerics NOT edited.i.e., pic S9(6)v99 and move using a
target of signed numeric.
It will take up smaller space anyway.
On 21/12/2024 17:34, J McNamara wrote:
Hi Vincent-
Thank you for the cool tip.
Unfortunately I tried it, and it did not work for some reason.
I tried inserting an edited picture, and I tried inserting a NOT edited picture.
Neither renders the decimal places in postgresql that I need.
I can insert it with regular postgres INSERT sql with psql, so I dont think it is a trigger that is causing it.
Who knows? It is for another day I guess - it is too close to Christmas to worry about it.
I am a 1 step forward 2 steps back cobol person until I get some more experience.
thank you so much,
jim
Sent with Proton Mail secure email.
Hi all-
I read in the example docs you are storing in comp-3.
So I guess this is to retain decimal and not do binary where you have to
divide by a number to get the decimal back.
Chatgpt said if it is in binary pic S9(13)v99 or such that it loses the decimal.
I didnt see you directly insert a parameter into INSERT like this :WS-AMOUNT
but I think that is probably it, that I didn't use comp-3 for the insert into postgres.
I saw in insert statements where you were using hard coded INSERT into emp_tbl (payrate) values (20.13) but not like INSERT into emp_tbl (payrate) values (:WS-PAYRATE) WHERE
working storage was populated from a value stored with a pic clause like this PIC S9(13)V99 COMP-3 VALUE 0.
I will check out later. I think this was the issue!
thanks
Have cool Christmas/holidays
jim
What is the definitions you have tried in the DB as this appears to be
the problem ?
For example I have :
INPUT-GROSSdecimal(14,2) unsigned NOT NULL,VAT-AMOUNT4decimal(9,2) NOT NULL,and here is an actual example for a Ledger table for nominal ledger
using my ACAS accounting product :
CREATE TABLE
IRSPOSTING-REC(KEY-4mediumint(5) unsigned NOT NULL,POST4-CODEchar(2) NOT NULL,POST4-DATchar(8) NOT NULL,POST4-DAYtinyint(2) unsigned NOT NULL,POST4-MONTHtinyint(2) unsigned NOT NULL,POST4-YEARtinyint(2) unsigned NOT NULL,POST4-DRmediumint(5) unsigned NOT NULL,POST4-CRmediumint(5) unsigned NOT NULL,POST4-AMOUNTdecimal(9,2) NOT NULL,POST4-LEGENDchar(32) NOT NULL,VAT-AC-DEF4tinyint(2) unsigned NOT NULL,POST4-VAT-SIDEchar(2) NOT NULL,VAT-AMOUNT4decimal(9,2) NOT NULL,PRIMARY KEY (
KEY-4)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;
/!40101 SET character_set_client = @saved_cs_client /;
Note that this has one of the few signed fileds using Mysql or MAriadb
Vince
On 22/12/2024 01:56, J McNamara wrote:
Vincent,
sorry the problem resolved itself with one try. I tried to write back.
The problem was comp-3. Otherwise, postgresql didn't accept it with a decimal.
I will read your thread carefully for reference but i fixed it simply by changing to comp-3 to retain the decimal.
It is very cool that you have an accounting project in COBOL. i know a little debit and credit and think it is very neat that you can do that in a programming language. I still have a lot to learn, and am hopeful that I have the opportunity to do it.
Have the coolest of holidays and thanks for reaching out to me.
The accounting people have to stick together. AI is literally displacing some accounting people. Those who know tech are in the best place to stop that from happening possibly.
I had an idea for accounting that A-L=OE and each account code had a class associated with it and i could use triggers and procedures to keep it in balance based on a sequence number but I know so little COBOL and postgresql that I struggle to implement it because what is simple for you guys is not for me. Think about that Exp class 4 is negative equity and REV class 5 is positive equity and you know the others you can see if you know the classification system and the effects on equity how easy it is to create the reconciler. But it takes experience like yours.
Interesting choice of database. I dropped learning firebird because if a lock or transaction goes kooky too hard to decipher from system internals for me. Everything is tied to the transaction id and if it is in a funk you need to be a db scientist to figure it out.
THANKS
jim
Sent with Proton Mail secure email.
On Sunday, December 22nd, 2024 at 8:27 AM, Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
If you want to take a look at ACAS go to
https://sourceforge.net/projects/acas/
You can go to files and select nightly build OR
Then select cvs-3.02 and then pick the "svn checkout" box (assuming you
have svn installed) to get the current version.
Note that this area can be updated almost daily as I am in the middle of
testing.
All manuals are included along with the LibreOffice writer sources in
ODF format.
I welcome help in testing and manual updating as all work is just me now
and it is a lot for one person and more so now that I will be 78 next June.
This was a commercial package until I migrated the entire system from
Micro Focus Cobol (very expensive paid version) to GnuCobol.
GnuCobol version used is v3.2 final as all others can be flaky, at least
as far as my testing shows.
On 22/12/2024 13:41, J McNamara wrote:
Hi Vincent-
I will look into checking it out. This is very cool to look at. But it will take me a bit to get to it as I am in the middle of a few things at once.
That is very cool you are on your way to 78..
Lord willing you will make it and then some. I am getting up there very close to senior. AARP wants to talk to me, but I am in hiding.
I know people in their early 70s and they are kind of spry for their age.
Its only a number.
Thanks for the opportunity to check out and interact with your cool software. I am especially interested in seeing navigation and menu systems and screen layouts.
thanks again,
jim
Sent with Proton Mail secure email.
On Sunday, December 22nd, 2024 at 9:03 AM, Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote: