|
Hi Marco
I see how an error log works for you - it does seem that the overloaded
piece is the varchar field, which has a different layout for each error
type. This seems something like IBM's table for database monitoring,
although they seem to have columns for everything, just some are not
used for some types of records.
We have what I imagine can be call transaction tables - they contain the
record of work done by our service specialists at the customer, and
there are several types of information to record - the customer
information, details of the kinds of service, details about which pests
were treated for, replies to survey questions that apply - so there are
several many-to-one items - all that would be very difficult to put into
a single table with enough fields to handle it all - and that would take
up a lot of space on disk, I believe.
I think I am still not completely comfortable with overloading a single
column with different kinds of information. But your use of views helps
very much, seems to me. Again, it is similar to the views IBM have
provided over the database monitoring table.
Raul's description seems to me that it would be used for more than the
error log - I might be mistaken in how I understand what Raul is saying.
It sounded like a flat file, that is internally described to get the
different types of data, maybe using record-identification entries.
Again, I may have completely misunderstood what Raul means.
Regards
Vern
On 12/24/2022 7:22 AM, Marco Facchinetti wrote:
Hi Vern we don't use this approach for transaction but (for us) it'suseful
and efficient for error logs.as
So one table with:
Error type
Common fields (Job, program, procedure, statement and so on)
Error type specific data in a varchar field (Price errors store item and
customer, Stock violations batch and qty)
Each error type has an SQL view mapping the fields in the varchar field
columns. RPG handles the varchar without problems (DS).specific
The advantages are:
- One service program to handle errors logging
- A single trigger can handle all the necessary actions: notifications,
specific actions on the db, ticket creation
- Flexible: a single point to query all the errors or, if needed,
program to query and handle specific error typepay.
Best regards
--
Marco Facchinetti
Mr S.r.l.
Tel. 035 962885
Cel. 393 9620498
Skype: facchinettimarco
Il giorno ven 23 dic 2022 alle ore 23:04 Vern Hamberg via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> ha scritto:
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
hasBanck 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
subscriptionmuch more context in it. I still find the idea of a single tabletables.
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
>
> 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
change>> 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
subscriptionlist 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
listrelated 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
relatedTo 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
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
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
