Un'altra informazione "flash": testare l'esistenza di un record, prima di inserirlo, funziona solo in ambito monoutente, non è minimamente affidabile in ambito multiutente, a meno di non imporre un lock globale sull'intera tabella (o tabellE), cosa che non so se è fattibile con Access/JET.
Diciamo quindi che è un approccio adatto per utilizzi "hobbystici".
Tornando alla domanda, e supponendo di voler fare un po' di didattica sui covering indexes (dal tipo di domanda ovviamente siamo molto lontani da questi problemi, ma d'altronde è un forum, magari a qualcun altro può interessare un livello più approfondito) segnalo che nulla vieta, se proprio ti sei "amminchiato" con l'indice, di definire altri due campi (o anche in realtà uno solo, giustapposto, o tipicamente anche con un CRC32 con successivo check in caso di collisione) che mantenga le informazioni, su cui imporrai un indice univoco.
Chiaro?
Vabbè supponiamo che, per qualche motivo, tu voglia avere un metodo efficiente per controllare se esiste un record che contiene due, tre o K campi già inseriti, ma per qualche motivo non vuoi (o puoi) definire un "indicione" su ogni campo.
Parimenti potresti aver interesse a considerare poniamo solo i primi J caratteri di una stringa molto lunga (campo blob, email, JSON o quello che ti pare), mantenendo però un indice di dimensioni modeste (come saprai gli indici "costano", soprattutto in fase di inserimento e modifica).
Bene, puoi usare un campo appoggio, chiamiamolo testaduplicato, in cui metterai (all'inserimento dei campi, o mediante trigger se il tuo RDBMS lo supporta, o insomma come ti pare) le informazioni.
Che so marca e vino? Memorizzerai qualcosa del tipo
marcax;vinonero+
marcax;vinobianco+
marcay;vinonero+
Poi, per verificare l'esistenza già di un record della marcax e vinobianco, porrai una selezione
...
WHERE ... AND (testaduplicato="marcax;vinobianco+" )
A cosa serve? Serve, perchè - ovviamente - nel mondo "vero" non memorizzerai la stringa intera, bensì (tipicamente) il suo codice CRC32 (che è un intero), sfruttando l'ottimizzatore delle query (se ce l'hai a disposizione) per imporre qualcosa del tipo (lo semplifico un poco), creando simil-indici-a-copertura a costo modesto
...
WHERE ... AND (testaduplicato="0xEBAAD76A") AND (marca="marca") AND (vino="vinobianco" )
La seconda porzione (i due AND aggiuntivi) considera la possibilità di una eventuale collisione CRC, anche nel caso in cui non esistano indici su marca e vino (la collisione CRC ti riporterà un numero minimo di righe, diciamo 2 o 3 nei casi peggiori, e quindi l'esistenza di indici è inutile, anzi addirittura negativa in questo caso)
Usualmente non si utilizzano metodi più affidabili, talvolta in realtà si "taglia" una porzione (8 byte) di un codice SHA1 per rendere praticamente impossibile (=ultrararissima) un'eventuale collisione.
Compendiando: problemi apparentemente semplici, come quello che ti poni, non sempre hanno risposte così banali come si potrebbe supporre.
Le hanno nel caso "hobbystico", ma non in quello "professionale".
Chiosa finale
In pratica, se inserisco "Toso Spumante Secco" mi dice è gia' presente,
mentre se scrivo "Toso Spumante" mi lascia inserirlo invece di dirmi che è gia' presente.
Generalmente non è un'idea ottima quella di consentire campi NULL che verranno poi "infilati" nelle chiavi indiciate.
Sia per i problemi che stai riscontrando, sia anche solo per motivi di performances (non faccio lo spiegone di come un campo NULL incida su un indice tipicamente ad albero).
Versione superbreve: risparmiati un certo numero di problemi, NON consentendo questa circostanza.