Problem:
User does not have access to LBI. See screenshot below.
Resolution:
First, go to Mingle/InforOS, then go to manage users, and then search for the user.
Next, click on the arrow shown below which will take you to the user profile.
Click on the Roles tab:
Then click on the + to add roles:
Next, search for Mingle Role for LBI and click on the +Add & Close:
Finally, Click the Save icon. And you should be good!
Lawson File Channels can be useful when importing files from a defined local Landmark directory or a remote one via FTP, SFTP etc. They are especially useful when a file from an outside organization is delayed. Unlike a IPA scheduler that only runs on a set schedule, a file channel will pick up a file that has been delayed for reasons outside of your organizations control.
First in Process Server Administrator, you need to go to Administrator >> Channels Administrator (assuming you have permissions)
Then create a new File Channel:
Now that you know how to create one, File Channels essentially act as a source directory path that is scanned every X minutes to then search for a file specified by a File Channel Receiver.
Below is an example of a File Channel searching a remote server via FTP:
Since the above is an FTP directory, it has a default directory upon connection. You then define the Source File Directory after that. If the FTP server connects and starts on ..\inbound directory, and your source directory is ..\inbound\APFinance, then Source File Directory is simple APFinance
Error file and In-Progress File Directory are always directories on the local Landmark server so make sure you establish those directories first.
Additionally, you can change the File Channel Type. Local is Landmark, Amazon S3 is a specified Amazon server instance:
All other Parameters are self-explanatory so let’s move on to File Channel Receivers.
You can have multiple File Channel Receivers defining different file names for every File Channel. This way if you have one Source Directory, you can search different file names like ACH_*.txt, APC_*.xml etc.
The “Process” field is the IPA process that will be processing the file.
The Data field is also important. File Data is the ideal selection.
File Name: Triggers one workunit with just the file name.
File Data: Triggers one workunit with the file’s entire contents.
File Line: Triggers a separate workunit for each line of the file.
Once the file is picked up, it moves it to the in-progress directory while it gets processed regardless the the Data field setting. The in-progress directory acts like an archive folder in this way.
That’s it, File Channels are great when receiving a file from an outside organization that sends it on a schedule. That way if it happens to be delayed, the File Channel will still scan it when it finally gets to Lawson.
When working with Aurora MySQL, it’s common to assume that running a TRUNCATE TABLE will completely clear out space and return your database to its pre-load size. Unfortunately, that’s not quite how it works — and it often surprises people during large migrations.
Here’s why truncating doesn’t always free space, and what you should do instead.
TRUNCATE vs. Space Reclamation
In MySQL (and Aurora MySQL), TRUNCATE TABLE is a fast operation that:
However, with InnoDB tables, the physical storage file is not always shrunk automatically. Instead:
That means your database volume won’t shrink even if the table is empty.
The Role of OPTIMIZE TABLE
To actually reclaim space after large deletes or truncations, you need to run:
OPTIMIZE TABLE your_table;
What this does:
In practice, many users see 20–40% of their allocated storage reclaimed after running OPTIMIZE TABLE on heavily churned datasets.
Aurora-Specific Gotchas
Best Practices
Final Takeaway
In Aurora MySQL, TRUNCATE TABLE clears rows but doesn’t guarantee space reclamation. To actually shrink your database footprint, you need to rebuild the table with OPTIMIZE TABLE. Think of it as the “vacuum” step — without it, your cluster will keep carrying dead weight.
This procedure explains how to subscribe to bookmarks.
You could also use the procedure to subscribe to bookmarks, if you have been given access to the bookmark by your system administrator. If the bookmark appears in your list, you have access to it. (See your system administrator if you need access to a bookmark that does not appear in your Bookmarks list.)
To subscribe to bookmarks
If the check mark is removed and you want to add it, click on the box.
Unchecked bookmarks will not appear in your navigation pane or content window.
Follow these steps to learn how to fix certain Lawson LBI reports on dashboard prompting for ID and Password. This typically happens after a migration to a new version of LBI. You’ll need to update these report parameters.
First, edit the report on dashboard:
Next, copy the existing URL:
Run the report in Report Admin with data refresh and grab this part of the URL (see screenshot), append it to the end of the original URL above from the report you’re adding it from:
It should like this:
Now it should load properly without asking for credentials.
If you’ve ever loaded a few terabytes of raw data into MySQL and then scratched your head when the database footprint grew larger than your flat files, you’re not alone. This question came up recently in a real-world migration: flat files totaled about 2.0 TB, but once ingested into MySQL (with no secondary indexes), the database measured 2.24 TB.
So where did the extra 240 GB come from?
The InnoDB Overhead Story
The main culprit is InnoDB’s design. It’s not just storing your rows — it’s storing them with transactional guarantees, recovery mechanisms, and structures for efficient querying. Here’s what adds up:
Every row comes with extra fields beyond your raw data:
A small per-row overhead scales up dramatically in large datasets.
InnoDB maintains:
Even when idle, these files persist on disk.
To keep inserts efficient, InnoDB intentionally leaves free space in pages. This means some storage is held open for growth, rather than packed tightly like in a flat file.
If you’ve done heavy deletes or updates, space may not yet be reclaimed. Running OPTIMIZE TABLE can help, though it’s resource-intensive.
How to Measure the Difference
You can check actual table storage in MySQL:
SELECT
table_schema,
table_name,
ROUND(data_length/1024/1024/1024, 2) AS data_gb,
ROUND(index_length/1024/1024/1024, 2) AS index_gb
FROM information_schema.tables
WHERE table_schema = ‘your_db’
ORDER BY data_gb DESC;
Or examine InnoDB tablespace allocation:
SELECT
table_name,
allocated,
file_size,
free
FROM information_schema.innodb_tablespaces;
Putting It Together
The 12% overhead (240 GB on 2 TB raw) is not unusual at all. In fact, it’s right in line with expectations:
| Component | Typical Contribution |
| InnoDB page + row overhead | 5–15% |
| Undo/redo logs, temp files | 1–5% |
| InnoDB system metadata | <1% |
| Fill factor, alignment | 2–10% |
Flat files are lean but fragile. InnoDB adds the structures that make MySQL durable, transactional, and queryable — and that extra space is the price of those guarantees.
Final Takeaway
If your MySQL footprint is a bit larger than your flat file source, don’t panic. That overhead is just InnoDB doing its job. And in large-scale systems, a 10–15% increase is expected — and often well worth the trade-off for reliability and performance.
Problem:
I was able to access the QA site and see the JE, however there is an issue. I am not seeing the “error” report for GL165 that we would normally see in v9 production. This is the report that tells us which records have an error and what the error is.
How do we see the error report? Is this a setting somewhere?
Below is an example from v 10 QA. The test JE has an error, and the GL165 report shows that there is an error, but it doesn’t tell me which record has the issue:
Resolution:
To resolve this, simple give your user access to the role which gives access to the IFTR.1 files that generate the error files. Then have the user run the job again.