Re: Regarding Synon -- MIDRANGE-L

I use a lot of SQL, But in some programs I use RPG setll, reade, chain,
etc.
All my displays are in web, and the links to more detail are choosen
according to the "nature" of each account.
Like: for the customer's line the link takes you to the cuenta del cliente
(sorry mixed spanish) whith the detail of purchases and payments.
For the "product" line it takes you to the stock program. (The stock
program uses the account transactions)
All the banck reports are taken from the account transactions.

At present I am on vacations and I only have my phone. At the end of
January I will be back home and I can share a link to do a demo and answer
questions vía meet.

El vie, 23 de dic. de 2022 17:04, Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>
escribió:

Hi Raul

It does sound like it works for your company - one question, can you use
SQL to process the table? It can be done in regular RPG, of course.

Regards
Vern

On 12/23/2022 11:53 AM, Raul Alberto Jager Weiler wrote:

Our transactions table has the format for accountig,
recording a sale: debe account number of custumer, invoice number,
descripción, amunt, etc. Haber one line for each ítem
For purchases debe: one line per ítem, haber provider account, etc.
Some fieles have sligty different meaning: for example expiry date in the
customer's récord is when we expect to colect, (null for Cash sales) for
products is "use before " for provider is time we need to pay.
Banck transactions use the document for the check number intead of the
invoice number.

Works very well, litle wasted fieds.

El vie, 23 de dic. de 2022 08:31, Vern Hamberg via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> escribió:

I'll jump in here - a [single] transaction table? We have several
transaction tables (tables that store events, I just read) like services
performed by our field associates. But we have several of those - I hope
the idea is not to use 1 transaction file to hold invoice header,
detail, other levels of detail needed. That feels like overloading to an
extreme - of course, it does seem IBM has a transaction table like this
that stores the results of running a database monitor. So many columns,
many not used for certain record types. Are we going back to
internally-defined data files with those record-identifier codes?
Another example I've seen is the activity we get from a bank.

Enough said - perhaps the original comment on transaction tables has
much more context in it. I still find the idea of a single table holding
many types of records to be unwieldy and outdated - SQL doesn't seem to
support this concept at all.

Regards and Happy Holidays!
Vern

On 12/22/2022 8:26 AM, Steve M via MIDRANGE-L wrote:

I will have to absolutely disagree with that statement - if you

properly design a system in 3rd normal form that inherently creates a
greater number of tables for any system. Extrapolating that statement -
the larger the system the more tables. Transaction tables have a place,
but they can't replace a well architected and well-designed enterprise
system.

Steve M.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of

Raul Alberto Jager Weiler

Sent: Wednesday, December 21, 2022 7:41 PM
To: Midrange Systems Technical Discussion <

midrange-l@xxxxxxxxxxxxxxxxxx>

Subject: Re: Re[2]: Regarding Synon

A well designed business system will not requiere hundred of tables.

A transactions table can hold information for many tasks, and Db2 can

handle big tables very efficiently.

El jue, 15 de dic. de 2022 16:00, Nathan Andelin <nandelin@xxxxxxxxx>
escribió:

When you develop broadly-scoped business systems consisting of
hundreds or perhaps thousands of database tables you'll need some form
of code generation with consistent user and programmer interfaces to
handle basic database inquiry and maintenance. That was a key for us,
and made it possible for us, a small company with just a couple
programmers, to gain a foothold into the public school software
market. Although there may be some really bad code generators out

there, I doubt that's the norm.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,

visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at

https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com