Archive for category: Articles

Follow this simple guide to learn how to resolve the Lawson PR140 Fatal Table error – See errors files.

A Lawson PR140 (Earnings and Deductions Calculation) fatal table error can mena many things like  the payroll job hit bad data, a lock conflict, or a stuck run flag in your environment files. You may come across this error:

PRDED-DED-TABLE must be increased; Cur size 0500

 

The error occurs when an employee has more than 500 deductions tied to them. This includes all open and closed deductions.

 

To fix this, apply the latest Secure Act 2.0 Patch from Infor since this is addressed in JT-1371703

Alternatively, you could also fix this error via CTP 123335.

If you’ve ever logged an environment variable in Python and thought, “Why is this value coming from my system instead of my .env file?” — you’re not alone.

This is a very common source of confusion when working with AWS credentials, profiles, or configuration-driven applications.

Let’s break down why this happens, how environment variable precedence works, and how to make your .env file behave the way you expect.

---

The Core Issue: .env Files Are Not Automatic

Calling:

os.getenv(“AWS_PROFILE”)

does not read your .env file by default.

Python only knows about variables that already exist in the process environment. A .env file is just a text file until you explicitly load it.

That’s why libraries like python-dotenv exist.

---

Loading the .env File Correctly

To load values from a .env file into the environment, you must do this explicitly and early:

from dotenv import load_dotenv

load_dotenv()

After this runs, variables defined in .env become available via os.getenv().

However, this alone does not guarantee your .env values will be used.

---

Environment Variable Precedence (The Real Gotcha)

Even when load_dotenv() is working correctly, system-level environment variables always take precedence.

If a variable exists in both places:

1. System environment (PowerShell, shell, OS)
2. .env file

Python will use the system value, not the .env value.

This is intentional behavior.

---

Forcing .env to Override System Variables

If you want the .env file to override existing environment variables, you must opt in:

load_dotenv(override=True)

Without override=True, python-dotenv will not replace values that already exist in the environment.

---

Verifying Where the Value Is Coming From

To debug what’s happening, it helps to inspect both sources:

from dotenv import load_dotenv, dotenv_values

import os

 

load_dotenv(override=False)

 

print(“Value in .env:”, dotenv_values().get(“AWS_PROFILE”))

print(“Value in environment:”, os.getenv(“AWS_PROFILE”))

This makes it immediately clear whether:

• the .env file was loaded
• the system environment is overriding it

---

Common Causes of .env Being Ignored

1. The variable is already set in your shell

On Windows (PowerShell):

echo $Env:AWS_PROFILE

If this prints a value, it will override .env unless override=True is used.

---

2. The .env file isn’t in the working directory

load_dotenv() searches relative to the current working directory. If your script runs from a subfolder, the file may not be found.

You can confirm this with:

import os

print(os.getcwd())

Or specify the file explicitly:

load_dotenv(dotenv_path=”/path/to/.env”, override=True)

---

3. The .env syntax is invalid

The .env file must use simple KEY=value syntax.

Correct:

AWS_PROFILE=dev

Incorrect:

AWS_PROFILE = “dev”

---

4. .env is loaded too late

Always call load_dotenv() before importing modules that read environment variables.

---

Key Takeaways

• getenv() only reads environment variables, not .env files
• .env files must be explicitly loaded
• System environment variables override .env by default
• Use override=True if you want .env to win
• Always verify where values are coming from when debugging configuration issues

Understanding these rules will save you hours of frustration—especially when working with AWS profiles, credentials, and multi-environment setups.

 

If you’ve ever run an Amazon Athena query using Boto3 and received an error stating that the S3 output location is invalid, you may have double-checked everything only to find:

• The S3 bucket exists
• The bucket is in the correct AWS region
• The output prefix is valid
• Permissions look correct

Yet the query still fails.

This is a surprisingly common issue, and the root cause is often not the S3 path itself.

---

Why This Error Happens

Athena is a regional service. When you start a query, it runs in a specific AWS region, and both of the following must be in that same region:

1. The Athena database
2. The S3 bucket used for query results

What trips people up is that the region used by the Boto3 Athena client determines where the query runs.

If the client is created without explicitly specifying a region, Boto3 falls back to:

• Your AWS CLI default region, or
• Environment configuration

If that default region does not match where your Athena database lives, Athena may report errors such as:

• “Invalid S3 location”
• “Database does not exist”

Even when the S3 bucket itself is perfectly valid.

---

The Key Fix: Specify the Region Explicitly

To avoid ambiguity, always create your Athena client with an explicit region that matches your Athena database:

import boto3

 

athena = boto3.client(

‘athena’,

region_name=’us-west-2′  # must match your Athena database region

)

This ensures:

• The query runs in the correct Athena region
• The S3 output location is evaluated correctly
• Athena can see both the database and the results bucket

---

Additional Best Practices

1. Always Use a Trailing Slash for OutputLocation

Athena expects the output location to be a directory, not a file:

ResultConfiguration={

‘OutputLocation’: ‘s3://your-results-bucket/athena/’

}

2. Verify S3 Permissions

The IAM role or credentials running the query must be able to write to the bucket:

• s3:PutObject
• s3:GetBucketLocation
• (Optionally) s3:ListBucket

Athena will create the output prefix automatically, but it must have permission to do so.

3. Don’t Assume S3 Region Is Enough

Even if your S3 bucket is in the correct region, Athena still fails if:

• The Athena client is created in a different region
• The database exists elsewhere

---

Will Explicitly Setting the Region Break Other Regions?

No. Explicitly setting region_name will not fail just because another region exists.

It only fails if:

• The Athena database is not in that region, or
• The S3 results bucket is not in that region

As long as all three align—client, database, and S3 bucket—the query will work.

---

Final Takeaway

When you see an “invalid S3 location” error in Athena, don’t assume the bucket is the problem.

More often than not, the issue is that:

Athena is running in the wrong region.

Explicitly setting the region on your Boto3 Athena client is the simplest and most reliable fix—and it prevents a lot of head-scratching later.