The “GetView” Cache Leak: Why Copying filters triggers hidden table scans.

Using Rec.GetView() to copy filters into a second record instance doesn’t just transfer string expressions, it can strip away the active index context. Without that context, SQL Server may ignore available indexes and fall back to massive, unindexed table scans. What should be a sub‑second query can balloon into tens of seconds per loop, hammering performance.

⚠️ The Problem: The Indexless String Copy
When you pass a filtered record variable around and call Record.GetView(), Business Central extracts a string representation of the current filters. However, GetView() defaults to a behavior that surprises many: it strips out the explicit key pointer (SetCurrentKey) by default unless you explicitly tell it not to.
When you apply that bare string back to another record instance via SetView(), the NST data layer generates a brand new SQL query structure. Because the SetCurrentKey context is lost, the SQL query optimizer has to guess the execution plan. Instead of performing a high-speed index seek, it frequently panics under heavy load and drops into an expensive full table scan.

🛠️ The Fix: Explicit Key Preservation
The Record.GetView() method accepts an optional boolean parameter: UseNames. When you pass GetView(false), or more strictly, when you want to preserve the explicit index path across execution boundaries, you must use the parameter correctly to include the active keys.
Even better, modern AL allows us to bypass string evaluation entirely in many scenarios by leveraging direct filter copying, but when you must transfer a full view state, always force the execution context to preserve the index.

Technical Grounding:
✅ SaaS Available: Yes.
✅ Runtime/Upgrade: Runtime.
✅ Bypasses Triggers: No, it exclusively optimizes the SQL statement generation layout.
Why It Matters
✔️ Deterministic Execution Plans: Forcing the view to maintain its key guarantees that SQL Server will reuse existing cache plans rather than compiling expensive, alternative table scan operations.
✔️ Zero Lost Filters: Protects the system from dropping index hints when transferring complex, multi-field user filters between UI pages and background processing routines.

☣️ The Trap: If you pass false to GetView, the returned string uses internal field IDs instead of localized names—this is perfect for raw performance, but it will throw a runtime error if you try to display that raw string directly to an end-user on a page layout.

✴️ The Bottom Line
Treat GetView with caution. Always validate that your copied filters preserve index usage, or risk turning efficient queries into crawl‑speed scans.