× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 <http://midrange.com> by shopping at
amazon.com <http://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 <http://midrange.com> by shopping at
amazon.com <http://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 <http://midrange.com> by shopping at
amazon.com <http://amazon.com> with our affiliate link:
https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.