Il form in questo caso si usa per fare una di queste due cose:

1-permettere a un nuovo utente di registrarsi
2-permettere a un utente registrato di modificare i propri dati.

Spesso, per comodità e per risparmiare tempo, si usa lo stesso file .asp sia per aggiungere che per modificare, inserendo una condizione, che proviene dal link che chiama il form. Supponiamo che la pagina .asp che contiene il form si chiami register.asp. Allora:

<a href=register.asp?mode=add>nuovo utente</a>
<a href=register.asp?mode=edit>modifica i tuoi dati</a>

In questo secondo caso, si presuppone ovviamente che l'utente sia loggato, quindi la pagina register.asp possiede l'id dell'utente (in genere l'id viene memorizzato come variabile di sessione). A scanso di errori, se l'utente é loggato non deve apparire il primo link, se non c'è un utente loggato non deve apparire il secondo link.

Se c'è la variabile di sessione, il file riconosce che l'utente XXX si è loggato, e quindi ci troviamo in modalità modifica, altrimenti ci troviamo in modalità aggiungi.

Le due operazioni differiscono fin dall'inizio, perché in modalità modifica è necessario aprire il database per prelevare i dati dell'utente da mostrare nelle caselle di testo, mentre in modalità aggiungi il database deve essere aperto solo al momento del salvataggio.

Una casella di testo, in modalità modifica, si presenta così (poniamo che il recordset aperto si chiami RS):

<input type="text" name="cognome" value="<%=rs("cognome")%>">

In modalità aggiungi, invece si presenta così:

<input type="text" name="cognome" value="<%=request("cognome")%>">

Perché request("cognome") e non una stringa vuota? Semplice, perché se alcuni dati del form non sono corretti il form deve ricaricarsi, senza salvare nulla, ma conservando i dati immessi per non costringere l'utente a digitarli tutti di nuovo (l'unica eccezione che si fa usualmente è la password). La prima volta, il request equivale a una stringa vuota.

Da notare che in tutte queste operazioni inerenti la modalità aggiungi, il database non viene mai aperto: l'apertura avviene solo quando tutti i dati sono corretti, per salvarli aggiungendo il nuovo utente.

Un'ultima cosa: questo mio discorso presuppone che il destinatario del form sia se stesso, che è la prassi più corretta. Quindi:

<form method="post" action="register.asp?mode=<%=request("mode")%">

Quando il salvataggio è avvenuto, si reindirizza a un'altra pagina che dice "operazione compiuta con successo", oppure alla homepage, o dove si vuole. In caso contrario non si esce dalla pagina.

Dovrei vedere il codice per mostrare di preciso dove sta l'errore, ma sicuramente hai aperto il database dove non c'è ancora bisogno, prelevando i dati, probabilmente quelli del primo utente registrato.

Non lo so, purtroppo anch'io conosco bene il VBscript e non il Javascript, ma a colpo d'occhio mi sembra che il metodo execute nella tua routine viene eseguito ogni volta, e quindi ogni volta l'elenco si apre e il cursore si posiziona sul SECONDO record (mostra.movenext). Il metodo execute deve restare fuori dal ciclo

In effetti i DTC sono roba da preistoria. Io non penso che il problema sia il numero di colonne. In genere l'errore che dici tu è determinato dal tentativo di inserire una stringa vuota in un campo che non lo consente, oppure di inserire caratteri in un campo numerico.

L'unico modo per saperlo, è provare ad utilizzare la funzione addnew SENZA il DTC e vedere cosa succede, ma prima di tutto contolla che i campi consentano lunghezza zero.

Salve, mi sono appena iscritto a questo forum, e non so se il topic che ho scelto è quello giusto. Non sono un esperto SEO, poiché le aziende per cui ho lavorato finora curavano principalmente applicazioni Intranet.

Ebbene: da diverso tempo mi trovo a sviluppare un programma per generare siti dinamici, che vengono poi riempiti e amministrati direttamente dai clienti. In parole povere, una specie di CMS (ma che esistesse questa categoria l'ho scoperto solo recentemente).

Il programma funziona con un unico file default.asp che genera tutte le pagine per tutte le aziende, chiamando continuamente se stesso e passando come minimo 3 parametri (id_azienda, template e cartella) per la homepage, che diventano poi 4 (+ id_pulsante) per tutte le altre.

Per finire, questo file default si trova all'interno di un frameset per conservare il nome del dominio iscritto al servizio: il cliente scarica la pagina Index.htm generata automaticamente (cioé il frameset: un frame a zero, e il frame che contiene un altro file che reindirizza al file default.asp comune passando come unico parametro l'ID dell'azienda) e la mette dove vuole. Date queste premesse, parlare di indicizzazione è una pura chimera: un URL replacer non basta.

Quindi per forza di cose ho dovuto risolvere il problema dei testi in maniera spartana: nel tag NOFRAME di questo file index faccio scrivere tutto il contenuto testuale del database, in attesa di sviluppare la soluzione più razionale: la generazione automatica di pagine STATICHE.

Nonostante tutti questi sbarramenti, alcune di queste pagine "virtuali", che quindi hanno l'indirizzo non del cliente, ma del sito che gestisce il servizio, sono finite negli indici dei motori di ricerca (soprattutto in Google) con una logica che ancora non ho avuto tempo di decifrare (non è un grosso danno: basterà configurare il file o i tag ROBOTS e aspettare... qualche mese).

Incuriosito, ho preso ad analizzare un caso specifico: la guida del programma, che a sua volta è un sito dinamico generato dal programma stesso. Questo sito, a differenza degli altri, possiede link diretti da parte del sito che gestisce il servizio, e non è un URL autonomo (in parole povere, appare come un sito, ma in realtà è una nuova pagina aperta da link del sito). In particolare, questo "sito" si compone di circa 50 pagine "virtuali" ed è linkato 120 volte: ogni volta cambia aspetto, ma l'unico parametro che cambia è il nome del template.

Ecco come si comportano i 3 principali motori di ricerca:

Google: indicizza tutto il "sito", con due templates. I nomi dei templates possono cambiare ad ogni aggiornamento, ma sono sempre due. Non il primo e il secondo o il penultimo e l'ultimo, ma due presi a caso.

MSN: non indicizza nulla.

Yahoo: indicizza solo la "homepage", ma 20 volte.

Le informazioni più attendibili sembrano quindi essere quelle fornite da Google: esiste un gruppo di N pagine, in più di una versione. Nel caso di Google, sembra non esserci nessuna difficoltà a risolvere con successo i link passati come querystring che, ripeto, passano ben 4 parametri.

Qualcuno è in grado di interpretare i risultati di questo test?

Grazie e saluti, auguri & complimenti per il forum, ecc ecc