When working with Amazon Athena, SQL syntax quirks can sometimes trip up even seasoned database professionals. In this post, we’ll look at several syntax patterns that come up often when building queries in Athena.
Common Table Expressions (CTEs) with WITH
Athena supports CTEs, which allow you to define temporary result sets that can be referenced later in the query.
✅ Correct usage:
WITH cte1 AS (
SELECT column1, column2 FROM some_table
),
cte2 AS (
SELECT * FROM cte1 WHERE column1 > 100
)
SELECT * FROM cte2;
❌ Incorrect usage:
WITH cte1 AS (SELECT * FROM table1)
WITH cte2 AS (SELECT * FROM table2)
SELECT * FROM cte1 JOIN cte2 ON …;
Athena requires all CTEs to be defined under a single WITH keyword, separated by commas.
Window Functions: LAG() and ROW_NUMBER()
When you need to look at values in previous rows or assign sequence numbers, Athena provides window functions:
- ROW_NUMBER()
Assigns a unique number to each row within a partition.
- ROW_NUMBER() OVER (
- PARTITION BY employee_id
- ORDER BY start_date ASC
- ) AS row_num
- LAG()
Retrieves the value from the previous row in a partition.
- LAG(salary) OVER (
- PARTITION BY employee_id
- ORDER BY start_date ASC
- ) AS prev_salary
These functions are especially powerful when tracking changes over time or comparing current and prior values.
BETWEEN is Inclusive
In Athena, the BETWEEN keyword includes both the lower and upper bounds of the range.
WHERE event_date BETWEEN DATE ‘2021-12-01’ AND DATE ‘2021-12-31’
The query above returns rows from December 1 through December 31.
If you want to exclude the upper bound, you’ll need to switch to an explicit condition:
WHERE event_date >= DATE ‘2021-12-01’
AND event_date < DATE ‘2022-01-01’
No APPLY, Use LATERAL Instead
If you come from SQL Server, you may be familiar with CROSS APPLY or OUTER APPLY. Athena does not support APPLY. Instead, you can achieve similar functionality with a LATERAL join.
SELECT e.*, x.*
FROM employees e
CROSS JOIN LATERAL (
SELECT *
FROM salaries s
WHERE s.emp_id = e.emp_id
ORDER BY s.effective_date DESC
LIMIT 1
) x
Here, LATERAL allows the subquery to reference columns from the outer query, just like APPLY would in T-SQL.
Key Takeaways
- Use one WITH clause with multiple comma-separated CTEs.
- Use window functions like LAG() and ROW_NUMBER() to track changes or assign row order.
- Remember that BETWEEN is inclusive in Athena.
- Replace APPLY with LATERAL joins when you need correlated subqueries.
By mastering these syntax patterns, you’ll avoid some of the most common pitfalls when writing Athena queries, and make your SQL more efficient, readable, and powerful.
AI Has A Data Problem – Causal Data May Solve It
NewsArtificial Intelligence (AI) may be powerful, but this article argues its biggest limitation isn’t the models — it’s the type of data we feed them. In a recent piece for Forbes, writer and AI expert Gary Drenik explores the idea that modern AI systems rely too heavily on observational, transaction-based data, and that a shift toward causal data could significantly improve results. The core problem is that most AI today learns from what has already happened — purchases, clicks, searches, and other behavioral signals. This makes models good at spotting patterns, but weaker when conditions change or when they need to explain why something is happening. The article contrasts this with “causal data,” which aims to capture the drivers of behavior before actions occur — things like intent, expectations, sentiment, and constraints. The argument is that this kind of data gives earlier and more meaningful signals about future outcomes than traditional datasets. A key point is timing. Transaction data reflects behavior after it happens, while causal signals can appear months earlier. By the time spending slows or revenue drops show up in the data, the underlying causes may have been developing for a long time.
Drenik also highlights a broader issue in enterprise AI: organizations are accumulating massive amounts of data, but much of it is noisy, delayed, or shaped by algorithms themselves. This creates scale without clarity — lots of information, but not always meaningful insight. Causal data, in contrast, aims to reduce guesswork by focusing on measurable drivers of decision-making. That can make models more robust, more interpretable, and more stable when conditions shift. The takeaway is that the next leap in AI performance may not come from bigger models or more data, but from better data — specifically data that explains why outcomes happen, not just what happened.
For Full Article, Click Here
Weekly Patch Notification: June 13, 2026
Articles, Frontpage Article, PatchesAI Is Changing ERP, Not Replacing It
NewsArtificial Intelligence (AI) is making enterprise resource planning (ERP) systems feel like they’re on the verge of reinvention — but, as this article in Forbes argues, it’s more evolution than replacement. In a recent Forbes article, Robert Kramer, founder and managing partner of KramerERP, examines how a new wave of AI-native ERP startups is challenging established players like SAP, Oracle, Microsoft, and Infor. These newer tools promise faster implementations, automated reconciliation, and simpler workflows — and they’re attracting significant investor attention. But the core argument is that ERP is not just software; it’s the operational backbone of the enterprise. It governs finance, procurement, inventory, payroll, compliance, and auditability. Because of that, it can’t be replaced by lightweight workflow tools or “AI layers” alone. The article draws a sharp distinction between automation and system-of-record responsibility. AI can accelerate tasks, but it cannot replace the governance structures that ensure accuracy, traceability, and regulatory compliance. In fact, applying loosely governed “vibe-coded” AI to ERP systems could introduce serious financial and compliance risks, especially in regulated industries. A major theme is data governance. AI performance in ERP environments depends less on model sophistication and more on whether underlying data is consistent, well-structured, and properly controlled. Without that foundation, AI simply scales bad decisions faster. Kramer also highlights how the ecosystem is evolving. Platforms like Snowflake, Microsoft Fabric, and SAP’s Business Data Cloud are becoming connective layers between ERP systems and AI applications, enabling more reliable data flow across the enterprise. Vendors like Infor and QAD are cited as examples of a more disciplined approach, where AI is embedded within industry-specific processes and governed workflows rather than layered loosely on top. Kramer’s takeaway is clear: AI is reshaping ERP, but it isn’t replacing it. The winners will be the systems that combine AI with strong governance, trusted data, and industry-specific operational rigor.
For Full Article, Click Here
A Guide to Managing Infor Year-End Updates for AP and Payroll
Articles, Frontpage Article, NewsThis article will give you all the information you need to know about the Infor Year End Regulatory Patching that will be released by the end of the year.
Why Year-End Updates Matter
As you probably know the YE regulatory patches
TimeLine
Infor will release a KB article at the end of November. That article contains the dates, and the documentation that is needed for patching. Make sure to subscribe/follow the article so that anytime they make a change to it, you’ll get notified.
The YE communication process starts in Nov and then the downloads will be available around the beginning of December. That is when the install files, the PDF and the change documentation will be available.
Products and Documentation
To get the documentation and downloads, log into InforXtreme and go to product downloads.
You should see a link to product search on the right-hand side.
Download Search
In the Product Search box, enter the year,2025, and Year-End. That search will return many links for all platforms. Look for the one that fits your organization
You only need to download what products you actually use so if you don’t run benefits out of Lawson, then you will not need to download the benefit Patch.
Reviewing The Changes
For the changes, once you get your tar file, untar them and then inside there’s will be two HTML documents one of them is a Delta read me and the other one is a regular read me file.
The Delta lists the major changes. It’s a one-page high-level view of what changes are in this patch. The regular read me file is more detailed. Review both of those and look for any job parameter changes on any forms or in a batch jobs, if there are any, it will require you to create a new batch job because the new parameters on the batch job will cause the fields to shift or move, so the old jobs parameters could be off once the patch is installed. The documentation will tell you if the jobs must be recreated because of perimeter changes.
other changes that may occur with YE patches
Form Changes
You want to review:
Installation
TESTING
Test in a non-production environment first before you apply the patches to production. Test several different types of processing just to make sure that nothing has been impacted by the changes.
Recommended Timeline (Nov–Jan)
Key Takeaways
Why a modern data foundation takes more than a new platform
NewsModernizing enterprise data systems is often less about technology upgrades and more about improving governance, consistency, and trust across the organization. In an article posted on CIO.com, enterprise technology expert and CIO Thai Vong argues that the hardest part of modernization is untangling years of inconsistent reporting logic, fragmented systems, and poor governance that accumulate over time. A major issue is that many organizations struggle with trust in their data. Different teams often use different definitions for the same KPIs, while business logic becomes scattered across ETL jobs, spreadsheets, scripts, and databases. As companies grow, these inconsistencies create reporting debt and make systems harder to scale or maintain. The article stresses that modernization should focus on restoring architectural discipline, not just upgrading tools. That includes separating ingestion, transformation, and reporting layers, reducing duplicated logic, and creating a single source of truth for critical metrics. Vong also emphasizes the importance of master data management, especially around customers, suppliers, and products. Without consistent definitions and deduplication, even modern platforms can still produce unreliable reporting. Platform selection should prioritize operational fit rather than just technical capabilities. The “best” platform is the one that aligns with the organization’s skills, governance model, and long-term operating structure without adding unnecessary complexity. The article also highlights the value of phased execution, medallion architecture models, and strong operational practices like CI/CD, monitoring, and environment separation. Finally, Vong warns against leading modernization efforts with AI before the underlying data foundation is trustworthy and well-governed.
For Full Article, Click Here
AI won’t fix your data problems. Data engineering will
NewsArtificial Intelligence (AI) may feel like a model problem on the surface, but as this article in CIO.com argues, most enterprise failures actually come down to something more fundamental: data engineering. The author, Carter Page, EVP of research and development at Astronomer, explains that organizations are investing heavily in models, compute, and tooling — assuming better intelligence will automatically lead to better outcomes. But the real issue is that AI systems often lack the business context needed to operate reliably inside an enterprise. The problem starts with fragmentation. Customer, billing, product, and usage data are typically spread across multiple systems, each with different definitions and timing. Humans can navigate these inconsistencies through experience and judgment. AI agents, however, act on whatever data they receive — which means incomplete or inconsistent context leads to quietly incorrect decisions at scale. Page argues that this shifts data engineering from a supporting role to a core operational one. It’s no longer just about building pipelines for analytics dashboards, but about creating trusted, real-time context that AI systems can safely act on. That includes entity resolution, data freshness controls, and strong lineage tracking so organizations can understand where data comes from and how reliable it is. It also highlights a second challenge: orchestration. As companies deploy more autonomous agents, they need infrastructure to manage scheduling, permissions, cost controls, human approvals, and auditability. In other words, AI agents require the same operational discipline as any critical enterprise system. Moreover, AI doesn’t fail because models aren’t smart enough — it fails when the underlying data and operational systems aren’t designed for decision-making. Strong data engineering and orchestration are what turn AI from a promising tool into a reliable business system.
For Full Article, Click Here
Amazon Athena SQL Syntax Quirks
Articles, Frontpage Article, NewsWhen working with Amazon Athena, SQL syntax quirks can sometimes trip up even seasoned database professionals. In this post, we’ll look at several syntax patterns that come up often when building queries in Athena.
Common Table Expressions (CTEs) with WITH
Athena supports CTEs, which allow you to define temporary result sets that can be referenced later in the query.
✅ Correct usage:
WITH cte1 AS (
SELECT column1, column2 FROM some_table
),
cte2 AS (
SELECT * FROM cte1 WHERE column1 > 100
)
SELECT * FROM cte2;
❌ Incorrect usage:
WITH cte1 AS (SELECT * FROM table1)
WITH cte2 AS (SELECT * FROM table2)
SELECT * FROM cte1 JOIN cte2 ON …;
Athena requires all CTEs to be defined under a single WITH keyword, separated by commas.
Window Functions: LAG() and ROW_NUMBER()
When you need to look at values in previous rows or assign sequence numbers, Athena provides window functions:
Assigns a unique number to each row within a partition.
Retrieves the value from the previous row in a partition.
These functions are especially powerful when tracking changes over time or comparing current and prior values.
BETWEEN is Inclusive
In Athena, the BETWEEN keyword includes both the lower and upper bounds of the range.
WHERE event_date BETWEEN DATE ‘2021-12-01’ AND DATE ‘2021-12-31’
The query above returns rows from December 1 through December 31.
If you want to exclude the upper bound, you’ll need to switch to an explicit condition:
WHERE event_date >= DATE ‘2021-12-01’
AND event_date < DATE ‘2022-01-01’
No APPLY, Use LATERAL Instead
If you come from SQL Server, you may be familiar with CROSS APPLY or OUTER APPLY. Athena does not support APPLY. Instead, you can achieve similar functionality with a LATERAL join.
SELECT e.*, x.*
FROM employees e
CROSS JOIN LATERAL (
SELECT *
FROM salaries s
WHERE s.emp_id = e.emp_id
ORDER BY s.effective_date DESC
LIMIT 1
) x
Here, LATERAL allows the subquery to reference columns from the outer query, just like APPLY would in T-SQL.
Key Takeaways
By mastering these syntax patterns, you’ll avoid some of the most common pitfalls when writing Athena queries, and make your SQL more efficient, readable, and powerful.
Weekly Patch Notification: June 6, 2026
Articles, Frontpage Article, PatchesBeyond the hype: The enterprise AI architecture we actually need
NewsEnterprise AI is moving away from the idea of a single “all-in-one” platform and toward something more layered, modular, and grounded in real organizational constraints. In a recent article for CIO.com, chief digital officer and futurist Sumantra Naik argues that the future of enterprise AI will look less like a unified system and more like a structured architecture made up of multiple coordinated layers. Naik’s main point is that early generative AI enthusiasm often overlooks how enterprises actually operate. In reality, companies rely on complex ecosystems of systems like SAP, Salesforce, Workday, and ServiceNow — each holding governed, high-value data that can’t easily be centralized or replaced. Instead of forcing everything into one model, the emerging approach is a federation of AI capabilities. At the base are “native AI” systems embedded directly into enterprise platforms, where models understand the context and structure of the data without it leaving the system boundary. Alongside this sits “sovereign private AI,” designed to handle internal tools, bespoke applications, and fragmented knowledge systems that don’t fit neatly into vendor ecosystems. These models are meant to extend AI capabilities across the long tail of enterprise data. Above these layers is orchestration — the coordination layer that connects agents, data sources, and workflows across the organization. This is where AI becomes operational, rather than just experimental. The key takeaway is that enterprise AI success won’t come from a single breakthrough platform. It will come from a layered architecture that respects existing systems, governance requirements, and real-world complexity, while still enabling intelligent automation across the business.
For Full Article, Click Here
Stop Cleaning Your Data. Use AI To Figure Out Which Info Matters
NewsEnterprise data strategy is being challenged by a counterintuitive idea: maybe cleaning and organizing data first is the wrong way to unlock AI value. In a recent article for Forbes, John Sviokla, HBS Executive Fellow and co-founder of GAI Insights, argues that many organizations are over-investing in data preparation while under-investing in finding the actual signals that drive decisions. The article opens with a sharp critique of the common enterprise mindset: “get your data ready first.” While this approach feels safe, Sviokla argues it often delays real AI value and leads companies to perfect datasets that may not even contain useful insights. Instead, the article proposes a shift toward a “signal-first” strategy. The key idea is simple: businesses should first identify which decisions matter, and then work backward to determine what data actually influences those decisions. This is where concepts like expected value of perfect information (EVPI) come in — if better information wouldn’t change a decision, then cleaning it adds little value. Sviokla also highlights that AI itself is better suited to messy, unstructured data than traditional analytics. Customer feedback, call transcripts, sensor data, and other “dirty” inputs often contain richer signals than highly structured but sanitized datasets. To illustrate the idea, it points to companies like Verisk Analytics, which built its business by aggregating real-world insurance and risk data tied directly to underwriting and claims decisions — effectively treating data acquisition as signal acquisition, not storage hygiene. The broader message is a reversal of conventional wisdom: AI shouldn’t wait for perfectly governed data. Instead, it should be used to discover which data is actually valuable in the first place. In this view, clean data without signal is just overhead — while even messy data can be a competitive advantage if it helps improve real decisions.
For Full Article, Click Here