Zoho Sheet DGET Function: Unique-Record Retrieval

Zoho’s official DGET documentation was retrieved on October 15, 2026. It documents the function in the rolling web service. The first release and last functioning version are unknown; this is not a historical build test. Mobile/offline parity is unverified. Results below are independently worked expectations, not captured Zoho Sheet execution. The datasets are fictional and fully specified.

DGET(database; field; criteria)

All three arguments are documented. database includes a header row and its records. field identifies the column to process, using either its quoted header text or a reference to that header cell. criteria points to a separate range containing the relevant header and condition. The condition column and the result field can be different.

Use semicolons as shown in Zoho’s English reference; adjust separators if the workbook locale requires it. A header reference such as E1 is unquoted, whereas a literal name such as “Amount” needs quotes. These examples use explicit field names, not an assumed numeric field index or omitted argument.

Create Items and enter these literal records in A1:D5. IDs, Item and Category are text; Price is numeric. In F1 enter ID and F2 enter P103. Put the formulas below elsewhere on the same sheet.

F1:F2 selects only row 4 in this dataset. The returned field does not have to be the ID used for selection.

The two Item formulas illustrate a header string and a reference to the header. A literal “B1” is not a reference to B1. Zoho’s own examples return names, reinforcing that DGET is not restricted to numeric aggregation.

Duplicate Items. Change only F2 from P103 to P102. F4/F5 become Cable, F6 becomes 8, and F7 becomes Tech. The source records remain unchanged. In a second original copy change only D4 from 1.25 to 1.5. With F2 still P103, F6 becomes 1.5 while Item remains Pen.

These controls check two independent dependencies: the criteria must point to the intended record, and the return field must point to the requested column. If both Item and Price change when only D4 changes, inspect the formulas rather than assuming that DGET has changed the underlying data.

On the original sheet put 12 in H2 for Quantity. In H3 enter =DGET(A1:D5;"Price";F1:F2) and in H4 enter =H2*H3. Expected values are 1.25 and 15. Label the output as an illustrative subtotal; it includes no tax, delivery, discount or rounding policy.

Changing F2 to P104 yields unit price 15 and subtotal 180. Changing only Quantity to 20 while the ID is P103 yields 25. Keeping the retrieved unit price visible helps identify a wrong key before it is hidden inside a longer calculation.

A successful result is not proof the table is suitable for financial commitments. Real price data need a currency, validity date and a policy for missing or duplicate identifiers. DGET does not supply those business rules.

A key such as P103 is unique in the supplied data. Category=Office would match both Notebook and Pen. Do not use that selection for a single-item retrieval or assume DGET chooses whichever record appears first. Likewise, a nonexistent ID cannot provide a valid matching item. The checked Zoho page does not give a complete function-specific mapping from zero or multiple matches to exact error tokens; those native outcomes remain unverified.

For a visible preflight on this clean table, =DCOUNTA(A1:D5;"ID";F1:F2) should be 1. This works because every ID is nonempty. A value other than one calls for investigation before using the retrieved price. This is a data check, not a claim about how all possible cells or malformed criteria are coerced.

Zoho includes the database-family remark that a blank condition below a header selects the whole field. That does not make a multi-record DGET request uniquely defined. Keep a specific criterion for normal use. On a separate table containing only header ID/Item and one record P200/Clip, a whole-table selection is a deliberately different one-record case, not justification for applying blank criteria to the four-record example.

The official DGET page lists shared name, type and reference errors. It does not exhaustively specify no-match behavior, mixed-type coercion, wildcard rules, duplicate header handling or every exact error token. Do not import those details from another spreadsheet product simply because the function name matches.

Start with the small dataset above. Confirm that the database includes row 1, the criteria header matches the intended field and all references point to the intended sheet. Inspect underlying cell contents rather than display formatting. Keep criteria outside the source records so editing a condition does not alter the database. A correct formula can still answer the wrong question if its range omits newly appended rows.

Before transferring a workbook, compare these controls in the destination app. This guide does not establish Excel, Numbers or other products’ syntax, error or version equivalence.

DCOUNTA supports the nonempty-ID preflight. DSUM and DAVERAGE are appropriate when the intended result aggregates several records instead of retrieving one.