Verifica esistenza campo in una tabella (vba)

di silverado60 il
25 risposte
Pochi posts
Iscritto da
dic, 2016
Messaggi
21

Buongiorno a tutti.

Avrei bisogno di verificare se un campo esiste su una tabella.

Grazie

25 Risposte

  • Super Famoso
    Iscritto da
    nov, 2011
    Messaggi
    21917

    Scusa, ma come mai?

  • Pochi posts
    Iscritto da
    dic, 2016
    Messaggi
    21

    In pratica ho l'istruzione che mano a mano che viene eseguito il codice, mi crea dei campi necessari. Questo all'inizio dell'esecuzione, poichè anche le tabella vengono create ex-novo. Ho in pratica 2 pulsanti, Importazione che mi importa da un file txt in una tabella e Elaborazione che tra le altre cose crea nella tabella importata dei campi che mi servono. A volte, se non spesso, non faccio rieseguire l'importazione per velocizzare l'esecuzione ma procedo con l'Elaborazione ed è a questo punto che arrivano i messaggi di errori perchè il campo è già presente.

  • Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi
    371

    Probabilmente, se esponi il codice VBA che utilizzi per eseguire le importazioni, qualcuno potra' esserti di aiuto, ma messa cosi' la cosa e' poco chiara

  • Molto attivo
    Iscritto da
    dic, 2022
    Messaggi
    519

    Decisamente ho capito molto poco, ma quando un utente chiede di creare campi in runtime in una tabella access mi preoccupo.

  • Utente Famoso
    Iscritto da
    feb, 2011
    Messaggi
    2186

    Beh, i comandi esistono per creare database, tabelle, campi e relazioni in runtime…

    Magari una domanda simile se l'è fatta chi ha scritto access: “devo capire se un utente sta creando un database esistente”…. Noooo se si è in grado di gestire queste eventualità non si apre un 3d chiedendo come si controlla se un campo esiste…

  • Super Famoso
    Iscritto da
    nov, 2011
    Messaggi
    21917

    Avevi già posto il quesito in

    https://www.iprogrammatori.it/forum-programmazione/access/access-vba-recordset-intercettare-nome-del-campo-t49820.html

    Si può fare utilizzando appositi oggetti e proprietà ( https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/field-name-property-dao )  ma la questione è che è sbagliato creare campi in una tabella in modo dinamico, vuol dire che qualcosa non va nel progetto del DB

  • Avatar di @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi
    8951

    Premesso la condivisione di quanto detto da Oregon, sicuro campanello di allarme…

     Public Function FieldExistsInTable(strTableName As String, _
                                    strFieldName As String) As Boolean
 
    Dim strDummy As String
 
    On Error GoTo FieldDoesntExist
    strDummy = DbEnginw(0)(0).TableDefs(strTableName).Fields(strFieldName).Name
    FieldExistsInTable = True
    Exit Function
 
FieldDoesntExist:
    FieldExistsInTable = False
 
End Function
  • Utente Attivo
    Iscritto da
    nov, 2018
    Messaggi
    441

    31/08/2023 - oregon ha scritto:

    Avevi già posto il quesito in

    https://www.iprogrammatori.it/forum-programmazione/access/access-vba-recordset-intercettare-nome-del-campo-t49820.html

    Si può fare utilizzando appositi oggetti e proprietà ( https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/field-name-property-dao )  ma la questione è che è sbagliato creare campi in una tabella in modo dinamico, vuol dire che qualcosa non va nel progetto del DB

    Perche' dici che e' sbagliato creare campi via codice?

  • Utente Famoso
    Iscritto da
    feb, 2011
    Messaggi
    2186

    01/09/2023 - amorosik ha scritto:

    Perche' dici che e' sbagliato creare campi via codice?

    Non è sbagliato ma inusuale.

    Bisogna sapere come gestirlo e perché hai la necessità di aggiungere campi.

    Queto genere di operazioni si fanno in un programma di update ed evocate una sola volta nell'esistenza del programma. Un po' come una prima installazione di un programma.

    Il codice esiste ma non per la gestione ordinaria del programma.

    Come attribuisci i nomi dei campi? Lo fa il programma o l'utente?

    Non è qualcosa da gestire da chiunque, soprattutto se quel chiunque chiede in un forum come si fa andando nel pallone per un messaggio di errore.

  • Super Famoso
    Iscritto da
    nov, 2011
    Messaggi
    21917

    01/09/2023 - amorosik ha scritto:

    31/08/2023 - oregon ha scritto

    Perche' dici che e' sbagliato creare campi via codice?

    Perchè presuppone la creazione dinamica di nuovi campi o la cancellazione di campi esistenti.

    Un Db ha una struttura fissa e ben studiata nella versione corrente

  • Utente Attivo
    Iscritto da
    nov, 2018
    Messaggi
    441

    Dire che “…e' sbagliato creare campi via codice..”  perche' “…presuppone la creazione dinamica di nuovi campi..”, e' un ossimoro

    Che un db abbia una struttura fissa, non e' scritto nella tavola delle leggi di Pdor-iana memoria  (Pdor figlio di Cmer, della tribu di Istar…)

    E' inevitabile che un db, per seguire le richieste normative o  di chi lo usa, debba essere adattato alle nuove esigenze

  • Super Famoso
    Iscritto da
    nov, 2011
    Messaggi
    21917

    In effetti la mia indicazione riguardava la necessità di cercare campi che presuppone la creazione/eliminazione dinamica. Ho sbagliato citazione.

    02/09/2023 - amorosik ha scritto:

    nella tavola delle leggi di Pdor-iana memoria  (Pdor figlio di Cmer, della tribu di Istar…)

    Simpatico ma fuori luogo. Non so dove tu lavori (o che esperienza equivalente tu abbia) ma dove lavoro io nessuno si sognerebbe di creare o eliminare colonne di tabelle in produzione da codice.

    02/09/2023 - amorosik ha scritto:

    E' inevitabile che un db, per seguire le richieste normative o  di chi lo usa, debba essere adattato alle nuove esigenze

    Vedo che non distingui i due casi.

    Le nuove esigenze si riflettono in una nuova struttura ben definita del DB che, dopo i test e collaudi su sistemi diversi, viene passata in produzione in seguito ad un fermo del servizio per l'implementazione della nuova versione.

    Completamente diversa è la creazione/eliminazione di colonne in tabelle in produzione dinamicamente via codice che non si fa e non è mercenario.

    Al massimo si creano intere tabelle temporanee per esigenze del motore Dbms e/o query/sp (per cui esistono aree e funzionalità apposite)

    Vale per Oracleo altri dbms che uso ma in generale

  • Utente Attivo
    Iscritto da
    nov, 2018
    Messaggi
    441

    02/09/2023 - oregon ha scritto:

    Vedo che non distingui i due casi.

    Le nuove esigenze si riflettono in una nuova struttura ben definita del DB che, dopo i test e collaudi su sistemi diversi, viene passata in produzione in seguito ad un fermo del servizio per l'implementazione della nuova versione.

    Completamente diversa è la creazione/eliminazione di colonne in tabelle in produzione dinamicamente via codice che non si fa e non è mercenario.

    Al massimo si creano intere tabelle temporanee per esigenze del motore Dbms e/o query/sp (per cui esistono aree e funzionalità apposite)

    Vale per Oracleo altri dbms che uso ma in generale

    Non distinguo perche' non c'e' niente da distinguere

    Se nel suo intero ciclo di vita una procedura software va a modificare la struttura del db (e lo fanno tutti per adeguarsi a nuove normative o richieste committente), allora la necessita' di “verificare se esiste un campo dentro una tabella” che e' la richiesta iniziale, e' pienamente giustificabile

    Cosa c'entri tirare fuori Oracle magari ce lo spieghi la prossima volta

Devi accedere o registrarti per scrivere nel forum
25 risposte