DGET in Collabora Office: Require One Matching Record before Returning a Field

• Introduced: the original Collabora release and launch date are not established by the reviewed sources.
• Availability: documented in Collabora Office 26.04 desktop help.
• Platform scope: online and mobile deployment support is not inferred from the desktop documentation.
• Checked: October 14, 2026. Function-specific documentation and independent controls; no native Collabora execution.

=DGET(Database; DatabaseField; SearchCriteria)

All three arguments are required. Database includes its header row. DatabaseField identifies the returned column, while SearchCriteria identifies the records to consider. Those columns can be different.

Use a quoted field header, a reference to its header cell, or its one-based position within the database. For a database beginning outside column A, field index one still means the database’s first column.

The source requires one matching record, not merely one distinct returned value. Multiple records remain ambiguous even if their target fields happen to contain identical values.

Enter this table in A1:D6. The phrase leave empty is an instruction to leave D3 physically empty, not a value to type.

Put Item in F1 and F in F2. Use F1:F2 as the criteria range, and calculate the following in separate empty cells:

The last three choices illustrate that the returned field is independent of the Item criterion. The cell-reference and index forms both select Units.

For literal text criteria in this guide, use whole-cell matching with the exact strings shown. Wildcards, regular expressions and substring matching depend on Calc’s calculation settings and are not assumed interchangeable.

Change F2 to Z. No record matches, so the documented DGET result is #VALUE! for either Units or Note.

Change F2 to B instead. Exactly one record matches. DGET on Units gives numeric 0, while DGET on Note gives the separately documented #VALUE! because D3 is physically empty.

The same error code can therefore represent either no matching record or an empty target field. Zero is a legitimate returned value and should not be confused with either condition.

DCOUNT with its field omitted can inspect matching-record count: =DCOUNT(A1:D6;;F1:F2) gives zero for Z and one for B.

Put Team in F4 and Units in G4. Put North in F5 and >4 in G5. These same-row conditions are joined by AND.

Only item F satisfies both, so =DGET(A1:D6;"Item";F4:G5) gives F and DGET on Units gives 6. All Units cells in this fixture are actual numbers, avoiding uncertain mixed-type comparisons.

If the Units condition is changed to >=3, items A, F and G match. DGET then has documented Err:502; it does not return A merely because A occurs first in the worksheet.

Put Units in F7 and G7, >=4 in F8 and <6 in G8. The repeated-header AND criteria select only A, whose Units value is four.

=DGET(A1:D6;"Item";F7:G8) gives A. Increasing the upper condition to <=6 includes F too, producing the multiple-record error.

The repeated header expresses two bounds on the same field. Placing the conditions on different rows would express OR and change the selected record set.

Restore the original fixture in a separate copy, then add a second record with Item F, Team North, Units six and Note Done. Expand the database range to include that added row.

The Item F criterion now matches two records. DGET still has documented Err:502, even though both Units values are six and both Note values are Done. It checks record uniqueness, not distinct-result uniqueness.

A matching-record count is therefore a useful diagnostic before treating a DGET value as a unique lookup. It does not by itself verify that the returned field is populated.

Keep three checks separate: a valid database/field specification, exactly one matching record, and a populated target field. A generic error fallback can hide all three causes behind the same label.

The dedicated source documents the no-match, multiple-match and physically empty-target cases explicitly. Formula-empty strings, source error values and a complete error-precedence matrix remain unverified here. The examples use distinct ordinary text labels and numeric quantities, with independently modeled selection results rather than native Collabora execution.

• Collabora Office 26.04: DGET.
• Shared database arguments and criteria rules.
• Editorial testing standards.

Complete function-specific and shared database documentation reviewed. Outputs are independent selection and arithmetic controls or explicit documented rules, not captured native results. Formulas use English names and semicolon separators.