DGET Function (Gnumeric)

Use DGET in Gnumeric to retrieve a field from exactly one matching record. Put ID 104 in the criterion below and =DGET($A$1:$F$7,"Score",H1:H2) returns the expected value 40. The conditions must identify one record, not merely one distinct value.

Use DGET when ambiguity should be treated as a problem, not silently resolved by taking the first matching row. It can return a text field or a numeric field from the selected record. The official Gnumeric reference documents this database function. Here, “database” means a rectangular worksheet range with a header row; it does not require a database server.

=DGET(database,field,criteria)

Database: include the headers as well as the data, for example $A$1:$F$7. One row represents one record. Do not start at row 2 and accidentally treat the first record as the header.

Field: identify the column to calculate, such as "Score". A column number is counted from the left edge of the database, starting at 1; it is not a worksheet column letter. The field being calculated can differ from the field used to filter records.

Criteria: supply a separate cell range containing matching column headings and the conditions below them. Conditions on the same row mean AND; separate condition rows mean OR. A record satisfying more than one alternative is still one selected record. The examples always provide all three arguments and do not depend on omitted-field behaviour.

Gnumeric’s manual uses comma-separated arguments in English notation. Localized names and separators may differ; follow your installed Function Wizard or formula editor. The examples deliberately use numeric Team/Class codes to avoid assuming identical text-pattern settings between programs.

Open a blank worksheet. Enter the six headers ID, Team, Class, Score, Factor, Note in A1:F1, then enter the records below in A2:F7. F3 must be truly empty: do not type the words “leave empty.” Place criteria to the right of the database and results in column K, so no result overwrites an input.

Download the input CSV. This CSV contains the six-column input table only, not formulas or prefilled criteria. Import at A1 and keep the empty Note field empty. The same fixture is used in the companion program guide to make cross-software comparisons reproducible.

Example 1 — fetch the score for ID 104

Put ID in H1 and 104 in H2. In K2 enter:

=DGET($A$1:$F$7,"Score",H1:H2)

Expected result: 40. ID 104 is on worksheet row 5, but DGET returns its Score value, not the row number. Keeping an ID separate from a display name makes this lookup easier to audit.

Example 2 — return a text field from the same record

Keep H1:H2 unchanged and enter in K3:

=DGET($A$1:$F$7,"Note",H1:H2)

Expected text: Ready. The selected record has not changed; only the requested field has changed. The field header identifies a column in the database, so it does not need to be one of the criteria headings.

Example 3 — identify a record with two conditions

Enter H5=Team, I5=Class, H6=2, I6=1. The two criteria are on one row and therefore mean AND. In K6 enter:

=DGET($A$1:$F$7,"Score",H5:I6)

Expected result: 30. ID 103 is the only record with Team 2 and Class 1. This works for the fixture, but if a new record later has the same team/class pair, the lookup will become ambiguous. A successful result today does not guarantee future uniqueness.

For a no-match example enter ID in H9 and 999 in H10. The formula =DGET($A$1:$F$7,"Score",H9:H10) has a documented no-match outcome of #VALUE!.

For an ambiguous example put Team in H13 and 1 in H14. The formula =DGET($A$1:$F$7,"Score",H13:H14) selects four records. Gnumeric documents #NUM! for multiple matches. These error outcomes come from official documentation; they were not observed in a native run for this guide.

You can audit uniqueness before retrieving a field by counting a reliably populated numeric ID:

=DCOUNT($A$1:$F$7,"ID",H13:H14)

Expected count: 4. A count of exactly 1 is the condition you need for this dataset. This is only a valid record-count check when ID is numeric and populated on every record. Do not count an optional field such as Note and mistake one populated note for one matching record.

Two matching rows can contain the same Score yet still represent two records. Do not replace a multiple-match error with zero without investigating it; zero might be a legitimate retrieved score. Add a genuinely discriminating criterion, use a unique record ID, or choose an aggregate such as DSUM when more than one record is actually intended.

DGET is not a sorting rule or a “latest record” operation. If the business question asks for the latest matching entry, the definition of latest and a tie rule must be supplied separately. Returning the first row is not a documented substitute for uniqueness here.

If a result looks wrong, check the selected record IDs before changing the arithmetic. A heading typed differently from the database header, a criteria range lacking its header, or a condition placed on the wrong row changes the selection. Keep criteria ranges tight: accidentally including an entirely empty alternatives row can undermine the intended restriction.

Inspect numeric inputs as numbers, not imported text with currency symbols or hidden spaces. These examples use valid numbers and one genuinely empty Note cell. They do not establish how every blank, formula-generated empty string, boolean, error cell or numeric-looking text is coerced in every release. The multiple-match error differs between these programs: Gnumeric documents #NUM!, while Apache Calc Help documents Err:502. The no-match outcome is documented as #VALUE! in both. These are documentation-level claims, not cross-application runtime observations.

Gnumeric’s function manual documents header text or an integer field selector. This guide uses explicit, populated fields; it does not claim that omitted-field conventions or numeric conversion of text match another spreadsheet. For large or changing data, expand the database range deliberately to include new rows. Absolute references such as $A$1:$F$7 prevent copying from shifting the range, but they do not make the range grow automatically.

The Apache OpenOffice Calc DGET guide uses the same input data and record-selection examples. The two official references document the same broad purpose and three-part database/field/criteria structure. That is not proof of identical error tokens, text matching, numeric coercion or file-format round trips. Start with these ordinary numeric cases, then test your actual workbook in each destination program.

Related Gnumeric functions: DCOUNT, DCOUNTA, DSUM, DMAX. Choose a different aggregate when the question changes rather than interpreting every numeric output as a total or a count.

Official references reviewed on 2026-10-12: Gnumeric database-function documentation and the companion program’s documentation. Argument order, header-based selection and the function’s purpose were checked against those references. The worked dataset, selected IDs and arithmetic are original examples, independently evaluated with a small Python model.

No native application run: these are expected results, not outputs observed in an installed Gnumeric application. No claim is made about the earliest release supporting the function or every platform. The documentation checked is English desktop-function documentation, not a mobile compatibility guarantee. Example-check record · Editorial standards.