G: Yep, you’ve got the name right—it’s Ninox 👍. And yes, you can absolutely set it up so you don’t accidentally add duplicates, though how you do it depends a little on whether you want Ninox to block the duplicate or just warn you.

Option 1: Use a Unique Field

• In the table where you store your karaoke songs, pick the field that makes the entry unique—probably Song Title + Artist together.
• Open your table structure, select that field (or add a combined formula field like SongTitle + " - " + Artist), and mark it as “unique” in the field properties.
• Ninox will then prevent you from saving if that same value already exists.

Option 2: Use a Trigger on Create

• In the table’s “Trigger after create” script, you can write something like:

let dupe := (select Songs where SongTitle = this.SongTitle and Artist = this.Artist);
if count(dupe) > 1 then
    alert("This song already exists in the database!");
    delete this
end

That way, if you add the same song twice, Ninox pops up a message and removes the duplicate.

Option 3: Use a Validation Rule

• When editing the field, you can also add a validation script to check for duplicates before saving. This doesn’t auto-delete but gives you a warning.

✨ For a karaoke list, the combined field marked unique approach (Option 1) is usually the easiest—it’s quick, clean, and doesn’t require scripting unless you want more control.

Do you want me to sketch out how to set up that combined Song-Artist unique field step by step, so you don’t even have to touch scripting?

G: Ah, good catch — imports are trickier because they can flood your table in one go 🚰. Ninox won’t automatically de-dupe during CSV import, but you can set things up so duplicates either get blocked or are easy to purge afterward.

Before Import

• Unique field still helps: If you already marked your Song–Artist field as unique, then any rows in the CSV that collide with existing records (or with each other) will simply fail to import.
• Ninox will show you an error list at the end of the import telling you which rows were skipped.

During Import

• There’s no built-in “merge” option. If you try to import duplicates into a unique field, Ninox drops them. If the unique rule isn’t set, all the rows (even repeats) go in.

After Import

• If you don’t use a unique field, you can run a script to find duplicates. For example:

let dups := select Songs group by SongTitle, Artist having count(*) > 1;
alert("Found " + text(count(dups)) + " duplicates.");

From there, you could expand it to list or delete the extras.

💡 Practical tip:
If you expect to import CSVs regularly, it’s usually safest to:

1. Add a unique combined field (SongTitle + " - " + Artist).
2. Run the import — duplicates won’t overwrite, they’ll just fail quietly.
3. Check the report Ninox gives you after import to see if anything was skipped.

That way, you can confidently load huge CSVs without manually scanning for doubles.

Would you like me to show you exactly how to set up that combined unique field so CSV imports automatically respect it?

G: You're absolutely right to notice that there’s no setting labeled “Unique Field” in Ninox—even in the paid version. That kind of built-in unique constraint simply doesn’t exist yet. It’s not a permissions issue or tied to your version. It’s a limitation of the platform itself. citeturn0search1

What others have said:

From the Ninox community forum:

“There is no ‘easy’ way to mark a field as ‘unique’ … The only way is to create a script that ensures there is no duplicate.” citeturn0search1

So, sadly, even though SQLite (which Ninox uses under the hood) supports unique constraints, Ninox has not exposed that functionality in its UI.

What you can do instead:

Since there's no native unique field, you'll want to build a workaround using scripting. Here are the most common approaches:

1. Trigger After Update / After Create

Use a script on the field or record that checks for duplicates and alerts the user.

For example, if your fields are Song Title and Artist:

let title := this.SongTitle;
let artist := this.Artist;
if count(select Songs where SongTitle = title and Artist = artist) > 1 then
  alert("This song (and artist) already exists!");
  // Optionally clear a field or delete this record:
  this.SongTitle := null;
end

This can run after the record is created or after a specific field is updated to immediately catch duplicates. citeturn0search4turn0search15

2. Formula Field to Flag Duplicates

You can add a Read-Only Formula field that marks records as “Duplicate” or “Unique”:

let t := this;
if count(select Songs where SongTitle = t.SongTitle and Artist = t.Artist) > 1 then
  "Duplicate"
else
  "Unique"
end

This way, duplicates are flagged visually and can be filtered or sorted out. citeturn0search5

3. CSV Import Scripted Handling

If you're using CSV imports, you can write a custom import routine (via script) that:

• Checks if a matching record exists (e.g. by Song + Artist)
• Updates the existing record if found
• Creates a new one if not

Here's an example pattern (adapted for your karaoke songs):

for row in csvRows do
   let existing := first(select Songs where SongTitle = row.Title and Artist = row.Artist);
   if existing then
     // Optionally update fields
     existing.Album := row.Album;
     // ... other updates
   else
     let newRec := create Songs;
     newRec.SongTitle := row.Title;
     newRec.Artist := row.Artist;
     newRec.Album := row.Album;
   end
end

This is similar to a real-world example shared for preventing duplicate products during import. citeturn0search3

4. Dashboard + Server-Side Script (Advanced)

If you're on the web version, there's a sample CSV import tool that uses a dashboard and server-side scripting to check duplicates across tables while importing. It’s more elaborate, but powerful if you want to streamline regular imports. citeturn0search10

Quick Summary Table

Final Thoughts

• Unique constraint isn’t supported natively—that’s normal across all versions of Ninox. citeturn0search1
• You’ll need to rely on scripting workarounds, especially for imports.
• Let me know if you'd like help writing that import script or setting up triggers—I’d be happy to walk you through it!

Would you like a ready-made Ninox script example tailored exactly to your Song-Artist karaoke setup?

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: TL;DR: Yes. Model each Power as a record with a child table of Effects. Each Effect is one “descriptor tuple” (e.g., Transform → Blue → Random → Only Basic Tiles). Because Effects are separate records linked to the Power, you can attach any number of them. Use small lookup tables (or Choice fields) for the parts of the tuple, and add a tiny script to prevent duplicate tuples on the same Power.

How to model it in Ninox

1) Tables (minimal, flexible)

• Characters (optional)
• Powers
  • Name (text)
  • Character (reference to Characters, optional)
• Effects (child of Powers; each row = one effect)
  • Action (Choice or reference) — e.g., Create / Transform / Destroy / Convert
  • Color (Choice) — Red / Blue / Yellow / etc.
  • Selection (Choice) — Any / Random / Selected / Area
  • Tile Class (Choice or reference) — Any / Basic / Attack / Strike / Protect / Countdown / Charged…
  • Qty (number, optional) — e.g., “up to 3 tiles”
  • Notes (text, optional)
  • Power (reference back to Powers; this is the parent link)
  • EffectKey (Formula; see below) — used to block duplicates

Tip: If you want a very stable vocabulary, make lookup tables (e.g., EffectAction, TileClass) and reference them. If you prefer simple and quick, use Choice fields.

2) Show variable Effects on a Power

In the Powers form, add a subtable view of Effects. That lets you add as many Effect rows as you need for that Power.

3) Make tuple duplicates impossible (per Power)

Add a Formula field on Effects named EffectKey:

// Effects.EffectKey (Formula)
upper(text(Action)) 
+ "|" + upper(text(Color)) 
+ "|" + upper(text(Selection)) 
+ "|" + upper(text('Tile Class')) 
+ "|" + if Qty then text(Qty) else "" end

Then in Effects → Trigger after create (or after update if you want to catch edits, too):

let k := this.EffectKey;
let p := this.Power;
if count(select Effects where Power = p and EffectKey = k) > 1 then
  alert("Duplicate effect for this power.");
  delete this
end

Result: you can add as many Effects as you want, but not the same tuple twice for the same Power.

4) Optional: human-readable summary

Add a Formula field on Effects:

// PrettySummary (Formula)
switch Action do
  case "Create" then "Create " 
  case "Transform" then "Transform "
  case "Destroy" then "Destroy "
  else text(Action) + " "
end
+ if Qty then text(Qty) + " " else "" end
+ lower(text('Tile Class')) + " "
+ if Color then "tiles to " + lower(text(Color)) + " " else "" end
+ "(" + lower(text(Selection)) + ")"

And on Powers, add a Formula to concatenate all child summaries:

// EffectsSummary on Powers (Formula)
concat(
  (select Effects where Power = this),
  "\n",
  PrettySummary
)

That gives each Power a compact, readable list of its variable effects.

CSV import notes

• Import Powers first (or include a stable external key like PowerCode).
• Import Effects afterward. Map the CSV to the Effects fields and link each row to a Power (e.g., via Power := first(select Powers where Name = row.PowerName) if you do a scripted import).
• The EffectKey + Trigger above will automatically block duplicate tuples—whether duplicates already exist or appear twice in the CSV.

Edge cases & alternatives

• Many-to-many metadata: If you later need richer filtering (e.g., board region, probability, AP cost interactions), just add more small fields to Effects or factor them into additional tiny lookup tables.
• Versioning / balance patches: Add PatchVersion (text/choice) to both Powers and Effects so you can snapshot changes over time without overwriting history.
• Validation-only: If you prefer not to auto-delete, replace delete this with this.Notes := "DUPLICATE"; and prevent saving by using an After update script that resets fields and shows an alert.

This structure gives you exactly what you described: each Power holds a variable-length list of standardized effect descriptors, with clean de-duplication and easy display.