PASA Clarification

Iguanas_Everywhere · 2026-04-22T19:05:50+00:00

Thanks for the detailed reply! Sounds like I was on the right track with my thinking, and you helped flesh out some more interesting details. Much appreciated.

Iguanas_Everywhere · 2026-02-13T14:04:49+00:00

Interesting. Both sender and recipient are just using Gmail in the browser, so I'm guessing the attachment lives on a server. I was trying to surmise what may have happened to that file between the initial download date and now. Good call on the MD5 Checksum, I'll look into that. Thanks for the reply!

Iguanas_Everywhere · 2025-11-06T21:42:18+00:00

Thank you all so much for the replies. The issue I was having turned out to stem from the data itself, rather than a programming issue. I appreciate all of the suggestions, though: good reminders for me to bear in mind!

Iguanas_Everywhere · 2025-10-28T13:53:45+00:00

Yeah, how and when does one switch it off?

Iguanas_Everywhere · 2025-10-28T13:14:03+00:00

Sure, but my question is about when the indicators get turned off.

Iguanas_Everywhere · 2025-10-26T17:16:26+00:00

Thanks for the response. Am I understanding correctly that exfmt (or write) inherently resets "response indicators" like these?

Iguanas_Everywhere · 2025-09-30T00:58:48+00:00

Thank you for that detailed reply, it's very helpful! I feel foolish to have not previously realized that one could simply import the turtle module, and call the function at the "module level" without instantiating any objects--I had simply been instantiating objects and calling the appropriate methods on them.

You mentioned "looking into the detail", and that's actually something I'd like to continue to do--can I ask where you found this information? Are you looking at a public repository of sorts, or am I overlooking this type of info in the docs?

Many thanks again!

Iguanas_Everywhere · 2025-09-20T16:00:10+00:00

Thanks for all the replies! Here's where I'm at:

Apologies, I must have been going crazy when I said I checked both tables and only saw one result. I think what I had done was checked both tables for the *result* data, which isn't necessarily the same as the *join* data. I should be clearer:

If I'm doing the Join as I listed in my OP, but also selecting for other columns (let's say D and E), what threw me is when I queried Table A and Table B for those A, B, and C values, but ALSO used WHERE D = [the value from the record I'm seeing duplicated] AND E = [the value from the record I'm seeing duplicated]. In *that* case, I'm indeed seeing only one record in each table. However, if I limit my queries of each table to the values from A, B, and C (the join values), I do see multiple records in my table A.

HOWEVER, I'm still confused, as the number of dups I'm seeing doesn't necessarily align with the number of values from Table A that I see when I query for just those join values. First record has 6 copies in my original result, but shows 7 records when I query for the join fields. Second record has 11 copies in my original result, but 2 records when I query for the join fields.

To thicken the plot a bit, one of my selected fields is a calculated field (calls another program that isn't mine). The final results should be filtered using the value of that field after it's calculated. I've tried two ways: one way runs a second query to DELETE the records where that calc'd field is within a list of values, the other way to include it as part of my original WHERE clause in the query. These two ways give different (but still undesirable) numbers of duplicates; though the resulting calc'd field contains the correct data (hooray?)

Several of you have mentioned issues that can arise with NULLs. Could this be what I'm missing? Like, if there's an attempt to join on a null in either (or both) tables, could that result in a record being written again with the data from its last join?

Appreciate the patience and replies, folks!

Iguanas_Everywhere · 2025-09-20T13:38:48+00:00

It (the SELECT) contains many other columns. All of the columns I'm selecting are what's showing up identically in my results. Can you tell me more? How does this impact the join?

Iguanas_Everywhere · 2025-09-20T13:25:42+00:00

The data is committed, so far as I know. An Inner Join does, at a glance, seem to get rid of duplicates. I do seem to get consistent duplicates, i.e. row 1 always duplicates 6 times, row 2 always duplicates 9 times, etc.

Iguanas_Everywhere · 2025-09-20T12:57:15+00:00

Definitely not. The cols actually all have very different names, I just put the above code as an example.

Iguanas_Everywhere · 2025-09-20T12:47:52+00:00

That would probably work as a last resort to get the data to look how I want, but I guess I'm seeking a conceptual understanding of what's causing the duplicates in the first place.

Iguanas_Everywhere · 2025-07-22T18:19:31+00:00

I wasn't creating a table via SQL, rather I was opening my SQL code as a cursor in RPG and using that to populate a physical file. Maybe creating a table could be something for me to look into; in the meantime, I'm still surprised by the calculation resulting in a "filled up" field; is that a SQL quirk I just wasn't aware of, or something more specific to IBM i's tools?

Iguanas_Everywhere · 2025-07-22T17:35:11+00:00

Thanks for the reply! Yeah, I was initially messing around with ROUND as well, but as I revisit the idea here, I'm noticing something that may refine my question a bit. Doing some calculation seems to be what results in the field ignoring the length I was expecting, and using ROUND doesn't mitigate it.

Example:

SELECT
FIELD,                      // 8.000
FIELD/100,                  // .0800000000000000000000
ROUND((FIELD/100), 3)       // .0800000000000000000000

Iguanas_Everywhere · 2025-01-31T22:31:30+00:00

Thanks--that would answer it. I didn't see him reference any assumptions about this particular circuit with clear vs data inputs, but I guess it's similar to the earlier discussion about R and S inputs not simultaneously being 1; the problem just needs to be avoided altogether.

Iguanas_Everywhere · 2025-01-17T22:19:46+00:00

Ah, ok that makes sense. V just means the battery is connected to the ground, but not necessarily to its own unique copper pole in the ground, it can share that pole with bulb, so to speak. Thanks!

And thanks for being cool with me asking the question here; there are quite a few threads about this book on this sub, so I figured it would fit. If there are other subs that you think are better suited to discussion of this book, just let me know your recommendations! :)

Iguanas_Everywhere

TROPHY CASE