bc-code-intelligence-mcp
Version:
BC Code Intelligence MCP Server - Complete Specialist Bundle with AI-driven expert consultation, seamless handoffs, and context-preserving workflows
95 lines (74 loc) • 4.25 kB
Markdown
title: "AL Record Find Early Exit"
domain: "sam-coder"
difficulty: "intermediate"
bc_versions: "14+"
tags: ["record-access", "performance", "early-exit", "database"]
type: "improvement-pattern"
category: "performance"
pattern_type: "good"
severity: "high"
impact_level: "high"
improvement_suggestion: "Implement early exit patterns for record Find operations to prevent unnecessary processing"
implementation_steps: ["identify-record-operations", "apply-early-exit-patterns", "validate-performance"]
validation_criteria: ["improved-performance", "reduced-database-load"]
technical_areas: ["al-code", "database"]
samples: "samples/al-record-find-early-exit.md"
# AL Record Find Early Exit
## Overview
Implementing early exit patterns for AL record Find operations prevents unnecessary database queries and subsequent processing when records don't exist. This fundamental performance optimization reduces database load and improves response times.
**Key Principle**: Always check Find() results before proceeding with record-dependent operations to avoid processing non-existent data.
## Strategic Framework
### Standard Find Pattern
```
if Customer.Find() then begin
// Process found record
end else begin
// Handle not found case
end;
```
### Early Exit Implementation
Replace nested if-else with guard clause pattern:
```
if not Customer.Find() then
exit;
// Process found record directly
```
### Performance Impact
Early exits eliminate unnecessary code execution when records don't exist, reducing CPU usage and improving user experience in data-sparse scenarios.
## Architecture Focus
### Database Efficiency
**Query Optimization**: Early exits prevent cascading database operations when initial record retrieval fails
**Connection Management**: Reduced database round trips improve connection pool utilization
**Memory Management**: Avoiding record processing when data doesn't exist conserves memory allocation
**Transaction Scope**: Early exits keep transaction scope minimal for non-existent record scenarios
### Error Prevention
Early exit patterns prevent null reference errors and invalid data processing that can occur when assuming record existence without verification.
### Code Flow Clarity
Guard clause implementation creates clear separation between record existence validation and business logic processing.
## Best Practices
### Implementation Patterns
- **Guard Clauses First**: Check record existence at procedure start before main logic
- **Consistent Error Handling**: Standardize response for non-existent records across application
- **Logging Considerations**: Log appropriate messages for record not found scenarios
- **Return Value Strategy**: Design clear return patterns for procedures with early exits
### Performance Optimization
- **Filter Before Find**: Apply appropriate filters before Find() to reduce search scope
- **Index Utilization**: Ensure Find operations use optimal indexes for best performance
- **Batch Processing**: Consider FindSet() for multiple record processing scenarios
- **Existence Checks**: Use IsEmpty() for existence verification without full record loading
### Error Handling Integration
- **Graceful Degradation**: Handle missing records without disrupting user workflow
- **Clear Messaging**: Provide meaningful feedback when records cannot be found
- **Recovery Options**: Offer alternative actions when primary records are unavailable
- **Audit Trails**: Log record access attempts for troubleshooting and analysis
## Anti-Patterns
### Avoid These Approaches
- **Assumed Existence**: Processing records without Find() verification
- **Nested Processing**: Deep conditional nesting instead of early validation
- **Ignored Return Values**: Not checking Find() boolean result before proceeding
- **Cascading Failures**: Allowing record-not-found errors to propagate through system
Failing to implement early exits in high-frequency operations creates cumulative performance degradation and unnecessary database load.
*Related patterns: al-record-filtering.md, al-database-optimization.md*
*Implementation examples: see samples/al-record-find-early-exit.md*