# Nav2009 Object Management

> NAV 2009 Object Management

- Skill: `whobat/nav2009-object-management` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add whobat/nav2009-object-management`
- Raw SKILL.md: https://api.skillmd.com/api/skills/whobat/nav2009-object-management/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: whobat (https://skillmd.com/u/whobat)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/whobat/nav2009-object-management

---


# NAV 2009 Object Management

> **There is no CLI.** `finsql.exe command=exportobjects/importobjects/compileobjects`
> arrived in **NAV 2013** — on NAV 2009 it fails with *"The program property 'command' is
> unknown."* Do **not** construct finsql command lines, and correct the user if they ask
> for one. On NAV 2009, object work is **manual in the Object Designer**; your job is to
> guide it precisely and to **verify the outcome via SQL** (which IS scriptable).

Full procedures, filter syntax, Import Worksheet rules, and the license matrix are in
[REFERENCE.md](REFERENCE.md).

## What you (the agent) do

1. **Prepare**: turn the user's request into exact Object Designer inputs — object type,
   an ID filter string (e.g. `32|50022|50026` or `50000..50099`), and the target file
   name/format. State the license requirement up front (.txt/compile = developer license;
   .fob import = end-user license is enough).
2. **Guide the manual steps** (concise, numbered — the user is in the Classic client):
   - **Export**: Tools → Object Designer (Shift+F12) → pick the object type → filter the
     ID column (F7) → select rows → File → Export → choose `.txt` or `.fob`.
   - **Import .fob**: File → Import → review the **Import Worksheet** (it shows
     new/changed/conflict per object — never blind-accept "Replace All" on conflicts).
   - **Import .txt**: File → Import — **overwrites without compiling**; objects MUST be
     compiled afterwards (mark → F11), and .txt import skips the worksheet entirely.
   - **Compile**: mark the objects → F11 (or Tools → Compile); fix errors one at a time.
3. **Verify via SQL** (read-only; this is the scriptable part). The `Object` table holds
   per-object `Type, ID, Name, Compiled, Date, Time, [Version List]`:

   ```sql
   SELECT [Type], [ID], [Name], [Compiled], [Date], [Time], [Version List]
   FROM dbo.[Object]
   WHERE [Type] = 1 AND [ID] IN (32, 50022, 50026)   -- Type: 1=Table 3=Report 5=Codeunit 7=XMLport ...
   ```

   After an import/compile, confirm `Date`/`Time` changed, `Compiled = 1`, and the
   `Version List` carries the expected tag. After an export, this confirms what versions
   were exported. Report discrepancies loudly.
4. **For "can we automate this?"**: answer honestly — not on NAV 2009. The supported
   options are: do it manually (this runbook), use a third-party object tool the
   organization may own, or upgrade the development environment (NAV 2013+ added the CLI).
   UI automation of the Classic client is fragile and a last resort — say so rather than
   recommending it.

## Production imports

Treat any import into a production database as high-stakes: require a backup first
(`nav2009-db-maintenance`), prefer .fob with a reviewed Import Worksheet, plan the
post-import compile, and schedule when Classic users are out — table-schema changes
require exclusive access and trigger a synchronization prompt (see REFERENCE).

## Related skills

- **nav2009-development** — what the objects should contain (review, version tags).
- **nav2009-db-maintenance** — the pre-import backup.
- **nav2009-troubleshooting** — post-import errors (compile failures, schema sync).