Visualizzazione dei risultati da 1 a 7 su 7
  1. #1
    Utente di HTML.it L'avatar di lyllo
    Registrato dal
    Apr 2001
    Messaggi
    832

    [vb] Gestire un DB con 65 campi

    ciao a tutti.

    cerco conforto e consigli su questa spinosa questione:
    ho un db access 97 o 2000, che contiene moltissime informazioni: circa 65 campi.

    suddividendo con Tab e cose del genere, la visualizzazione del form di lavoro, non ho problemi a far visualizzare tutti i campi che mi interessano.

    esiste un solo, ma insormontabile problema quale quello della gestione in tempo reale di un così grande numero di valori.

    in queste condizioni non si riesce ne ad aggiornare ne ad eliminare alcun record senza provocare errori ingestibili. (perchè se l'utente voleva eliminare il record ed io blocco la funzione... stiamo punto d'accapo)

    conkranz molto genitlmente e stoicamente mi aveva consigliato di suddividere il db in più tabelle per ridurre il numero dei campi da gestire in un'unica tabella.

    mia veva anche fornito un db con le relative modifiche.

    solo che, e qui nasce il problema, come fare per:

    1) collegare ciascuno dei 65 controlli al relativo campo nella relativa tabella
    2) far si che, alla richiesta di aggiunta/eliminazione di un record, le tabelle siano sincronizzate e quindi tutte le informazioni di uno stesso record, suddivise in più tabelle rimangano cmq in ordine.

    se decideste di rispondere, vi prego di inserire un codice di esempio: non sono così ferrato da poter semplicemente sfruttare un vostro consiglio: non ho le conoscenze sufficienti a gestire automnomamente una situazione del genere.
    (ma visual studio.net è più felssibile in tal senso?)

    grazie.


  2. #2
    Utente di HTML.it L'avatar di Gigi84
    Registrato dal
    May 2001
    Messaggi
    569
    purtroppo mi picchierai perchè non ho l'esempio però prova la spiegazione: :gren:

    devi legare le tabelle trami un campo che avranno tutte in comune, per esempio lo chiamiamo ID, esempio: il record 1 della prima tabella avrà ID 001 , il record 1 della seconda tabella avrà ID 001 e così via..

    Poi imposti delle relazioni Uno a uno sulle tabelle (Strumenti-->Relazione) e imposti le relazioni sui campi ID delle tabelle.

    Inoltre spunti Applica integrità referenziale di modo che ti faccia l'eliminazione a catena ( cioè quando elimini il primo record della tabella1 (che ha ID 001) ti elimina il primo record della tabella2 (che ha ID 001))

    e anche l'aggiornamento..

    So che non ti ho dato una spiegazione completa, ma non so nemmemo la realtà del problema, in generale fai così.. ti ho dato solo uno spunto!


  3. #3
    Utente di HTML.it L'avatar di darkblOOd
    Registrato dal
    Jul 2001
    Messaggi
    2,212

    Re: [vb] Gestire un DB con 65 campi

    Originariamente inviato da lyllo
    ...conkranz...
    :quote: :quote: :quote: :quote: :quote:
    e chi è sto tizio?



  4. #4
    Utente di HTML.it L'avatar di vonkranz
    Registrato dal
    Sep 2001
    Messaggi
    1,387

    Re: Re: [vb] Gestire un DB con 65 campi

    Originariamente inviato da darkblOOd

    e chi è sto tizio?
    Anche se suppongo che tu l'abbia immaginato, il povero martire sono io.
    In effetti appena l'ho letto sono svenuto e, dopo essermi ripreso l'ho messa sul ridere.

    Ma dimmi tu se uno impiega 700 e fischia post per crearsi un nome e guarda come te lo trattano! una C al posto di una V ed e' tutto da rifare.
    :quote:

    X Lyllo:
    Guarda che sto' solo scherzando OK!

    Ri-X Lyllo :
    Rileggiti quello che ti ho mandato in proposito, li' ti ho scritto come fare per copiare i vari Join dopo aver creato le query con access (visto che hai molte tabelle).
    ...and I miss you...like the deserts miss the rain...

  5. #5
    Utente di HTML.it L'avatar di lyllo
    Registrato dal
    Apr 2001
    Messaggi
    832
    Conkrank... NON capisco!!!!!!

    non è che sia deficiente (magari è pure così..)

    ma per te che lavori a livelli un pò più seri può essere facile... ma per chi, come me non lo fa non è chiaro.

    la query che avevi creato in access, la dovevo semplicemnte incollare nella sezione SQL della finestra propretà del controllo ado?

    se faccio copia-incolla, il comando di aggiunta record rimane invariato?
    .rs.addnew? e basta? e poi fa tutto lui?

    se hai visto il form come l'ho strutturato, dici che è compatibile con la modifica che hai fatto al mioo db?

  6. #6
    Utente di HTML.it L'avatar di vonkranz
    Registrato dal
    Sep 2001
    Messaggi
    1,387
    Conkrank... NON capisco!!!!!!
    ...tra un po' non sapro' piu' come mi chiamo.... Gesu'!

    Fammi fare un po' di mente locale e appena posso vedo di metterti giu' una paio di righe.

    Anche perche' su strutturazione e razionalizzazioni di DataBase,JOIN (interni, esterni) e SQL in genere, sono stati scritti interi libri!

    Diventa complicato cercare di riassumere il tutto in poche righe (e magari pure comprensibili).

    Vedro' cosa riesco a fare,.... ma la vedo dura!
    ...and I miss you...like the deserts miss the rain...

  7. #7
    Utente di HTML.it L'avatar di lyllo
    Registrato dal
    Apr 2001
    Messaggi
    832

    con...kranz

    allora ho copiato ed incollato la query.

    ho modificato i campi che servivano (alcuni nomi erano sbagliati)

    ma all'avvio del programma mi dice che mancano delle informazioni fondamentali per proseguire, e quindi il prog si apre, ma non visualizza una mazza.

    in effetti mi chiedevo: ma i campi ID (chiave priamria) non diventano poi obbligatori? (se è così è male, ma cmq stic@..)

    però resta questo problema...
    e cmq poi vorrei capire se in questo modo "l'uso" dei metodi per l'ado (add, delete etc) roimangono invariati, e se con queste tabelline più piccole l'importazione/esportaizone del db è valida o rischia di dar problemi come me ne dava quella con un gran numero di campi tutti insieme.
    (ma se non lo capisco e me lo dici tu va bene uguale... )

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.