Archive for category: Frontpage Article

Summary: When setting up a Distribution group so other users can view the print manager of another user, typically a system user like lawson. You need to complete a very important step before being able to add it.

1. In Jobdef when you try and set the distribution group you get the “Distribution List Has Not Been Defined” error (not displayed below, but it’s an example of it being set)
   
2. To resolve, go to users environment info shown below in ISS (This can be done in LSA or ISS)
   
3. M sure to add the distribution group to the environment info of the Lawson user (assuming you’re distributing a lawson job to other users).
   
4. Open jobdef and add it now. NOTE: After adding to Jobdef, you can clear this field and it should still work.

Problem:

You’re trying to release a Journal Entry on GL40.1 but getting a “Workflow is not enabled” error (see example screenshot below):

Solution:

This is a simple resolve. First, on GL10.1, inquire on the company and under the Journals tab, set workflow to No >> Click Change

Go back to GL40.1 and release journal entry. This should remove the error and fix things. You’re done!

NOTE: This issue may happen when your GL10.1 form is a custom form and has customizations for the Workflow field.

Follow these steps to update a user’s DB password via Infor Lawson Cloudsuite

1. Login to your concierge account and go to Cloudsuite app (this assumes you have access to this else open a ticket with Infor).
2. Create a Service Request
   
3. Select Deployment and Request Type: SQL Manage User
   
4. Select Database Server and in the drop down select Change Password
   
5. Enter username, the new password for the user, then click Submit
   

All done! Validate with the user. If this is something you’re need assistance managing, Nogalis offers a team of Lawson specialists within a single MSP services contract for customers. Let us know if we can assist you today.

When working with MySQL, you might notice something surprising: a query that runs quickly on its own suddenly becomes slow when you try to save the results into a temporary table.

For example, let’s say you run a SELECT query that completes in about two minutes. But when you try to capture those results with:

CREATE TEMPORARY TABLE table_name

SELECT field1, field2, field3;

the process hangs, forcing you to kill it after five minutes. What’s going on here?

Why It Happens

When you run CREATE TEMPORARY TABLE … SELECT, MySQL is actually doing two jobs:

1. Running the SELECT – fetching rows from the source tables, applying filters, joins, and any transformations.
2. Creating and populating the temporary table – defining a new schema on the fly and writing the rows into it.

That second step adds overhead. Here are the most common reasons for the slowdown:

• Data Volume: Copying millions of rows into a new table takes time, even if the query itself executes quickly.
• Indexes: Your source query might benefit from indexes, but inserts into the temporary table don’t—MySQL has to write all rows one by one.
• Storage Engine: By default, temporary tables may spill to disk if they exceed memory limits, which is much slower.
• Server Resources: CPU, memory, and I/O pressure can cause inserts into the temp table to crawl.
• Locking/Concurrency: Other queries on the same data can introduce waits and contention.

Creating a Temporary Table in Memory

If your dataset isn’t too large, you can speed things up by creating the temporary table in memory instead of on disk. MySQL supports this via the MEMORY storage engine:

CREATE TEMPORARY TABLE temp_in_memory (

id INT,

name VARCHAR(255)

) ENGINE=MEMORY;

Then, you can insert data directly into this in-memory structure:

INSERT INTO temp_in_memory

SELECT field1, field2

FROM source_table;

Because the table lives in RAM, inserts and reads are much faster—though the tradeoff is size limits (governed by the max_heap_table_size and tmp_table_size settings).

Best Practices

If you’re seeing big slowdowns when creating temporary tables, try:

• Reviewing and optimizing your SELECT query with proper indexing.
• Using ENGINE=MEMORY if your temp dataset fits in RAM.
• Monitoring resource usage during the query (SHOW PROCESSLIST, or performance schema tables).
• Splitting large inserts into smaller batches.
• Making sure the temp table schema only includes the columns and datatypes you really need.

Takeaway

A SELECT query that runs fast doesn’t always translate to a fast CREATE TEMPORARY TABLE. The extra overhead of creating and writing the table can introduce new bottlenecks. If you only need the results for lightweight, session-specific work, an in-memory temporary table (ENGINE=MEMORY) can be a game-changer.

By understanding how MySQL handles temporary tables under the hood, you can choose the right approach and keep your queries moving fast.