Salve a tutti =)
più e più volte sono incappato in questo messaggio di errore, di per se è tutto chiaro... non posso fare select che restituiscano più di 8094 caratteri (credo), la mia domanda quindi è:
Da che dipende questo limite? dipende da sqlserver? e nel caso dipende dal fatto che non è aggiornato o vale per tutte le versioni? o invece dipende da qualche file di configurazione?

Se il limite è invalicabile, come si spiega la presenza di un campo 'text' che permette di memorizzare 2147483647 caratteri? ho letto in giro che, cito testualmente, "I dati di questo tipo, non vengono memorizzati nelle normali pagine dati di SQL Server, ma sono tratati in modo speciale su apposite pagine di memorizzazione", ma cosa implica questo? che se faccio una select con anche un campo text non ho più il problema degli 8094 caratteri?

Come sempre ringrazio per la disponibilità.


Davide

salve,
doppiomango wrote:

Salve a tutti =)
più e più volte sono incappato in questo messaggio di errore, di per se è tutto chiaro... non posso fare select che restituiscano più di 8094 caratteri (credo), la mia domanda quindi è:
Da che dipende questo limite? dipende da sqlserver? e nel caso dipende dal fatto che non è aggiornato o vale per tutte le versioni? o invece dipende da qualche file di configurazione?
Se il limite è invalicabile, come si spiega la presenza di un campo 'text' che permette di memorizzare 2147483647 caratteri? ho letto in giro che, cito testualmente, "I dati di questo tipo, non vengono memorizzati nelle normali pagine dati di SQL Server, ma sono tratati in modo speciale su apposite pagine di memorizzazione", ma cosa implica questo? che se faccio una select con anche un campo text non ho più il problema degli 8094 caratteri?
Come sempre ringrazio per la disponibilità.
Davide

la gestione dei dati text/ntext non e' uguale alla gestione delle "stringhe" pure... i valore text/ntext vengono "automagicamente" convertiti in varchar nvarchar solo nel caso rientrino nello spazio di allocazione massimo per il tipo di dato relativo, nel caso specifico solamente per 8000 caratteri (varchar).. per gestire le parti "eccedenti" si devono utilizzare le apposite funzioni puntatore textptr e readtext e simili in modo da ottenere chunks gestibili di dato.. ed inoltro, come ben sai, non sono ovviamente indicizzabili...
il limite dipende dall'architettura di storage interna e di gestione del tipo di dato... la cosa e' stata "modificata" a partire da SQL Server 2005 dove i tipi di dato sono stati deprecati in favore di varchar/nvarchar(MAX), che permettono la medesima allocazione, gestione e storage, ma con tutte le comodita' di operare su tipi di dato stringa puri... laddove possibile sarebbe indicato passare da binary/text/ntext alla controparte rinnovata, varchar/nvarchar/varbinary(MAX)...
saluti

salve,
doppiomango wrote:

innanzi tutto grazie a entrambi per aver risposto alle mie domande =) in merito al campo text e al relativo puntatore binario ho letto su msdn questo "avvertimento"
Questa caratteristica verrà rimossa a partire da una delle prossime versioni di Microsoft SQL Server. Evitare di utilizzare questa caratteristica in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. Non è disponibile una funzionalità alternativa.
Questo cosa comporta? che ci sarà un nuovo sistema per il campo text? o che invece sparirà?

l'alternativa c'e' a partire da SQL Server 2005 con i varchar/nvarchar(MAX) ed i varbinary(MAX), che vanno a gestire i dati LOB in maniera sicuramente superiore..
tutte le funzionalita' "deprecate" hanno qualche versione successiva di supporto, quindi non saranno piu' supportatem per poi alla fine essere abbandonate non piu' presenti...

@Andrea Montanari
il limite dipende dall'architettura di storage interna e di gestione del tipo di dato... la cosa e' stata "modificata" a partire da SQL Server 2005 dove i tipi di dato sono stati deprecati in favore di varchar/nvarchar(MAX), che *permettono la medesima allocazione, gestione e storage, ma con tutte le comodita' di operare su tipi di dato stringa puri...*
cosa comporta questo? che ora posso aumentare il valore dei varchar? e quando faccio la select ho ancora il limite di 8094 caratteri?

con il tipo di dato varchar(MAX) puoi esplicitare SELECT (teoriche) fino al limite stesso del tipo di dato (2g
http://msdn.microsoft.com/it-it/library/ms176089.aspx

cmq ho sql server 2003 e tali domande le faccio per capire se è il caso di passare ad una versione successiva o se è possibile continuare con l'attuale versione che a parte il problema attualmente trattato non crea particolari disagi, considerando che non sono un utilizzatore del campo (n)text/image/binary.

SQL Server 2003 NON esiste... le versioni esistenti/esistite sono 4.2, 6.0, 6.5, 7.0, 2000, 2005, 2008, 2008 R2...
SQL Server 2008 R2 e' la versione attuale.
saluti

salve Davide,
doppiomango wrote:

errore mio... la versione è 2000
con il tipo di dato varchar(MAX) puoi esplicitare SELECT (teoriche) fino al limite stesso del tipo di dato (2g
http://msdn.microsoft.com/it-it/library/ms176089.aspx

non ho capito benissimo... (perdonami ma le mie conoscienze in materia sono basse)... tu intendi il caso in cui debba fare select di un singolo dato? che in quel caso essendo il limite di 8000 caratteri il problema non si pone... ma se dovessi avere invece necessità di 2 campi varchar da 8000 caratteri o, più probabilmente, uno svariato numero di campi la cui somma dei caratteri superi i famosi 8094? in quel caso avrei ancora il problema di prima?
grazie infinite per la pazienza ed il supporto =)
Davide

allora...
in parole molto povere, SQL Server utilizza per l'allocazione su disco un formato base minimale detto "pagina", che da SQL Server 7.0 ad ora e' basato a 8kb...
precedentemente a SQL Server 2005, ogni singola riga non poteva eccedere una singola pagina, quindi 8kb teorici (qualcosa meno, come hai gia' ben evidenziato, visto che serve spaziona anche per header di pagina, stati di riga, indicazione di nullabilita' e quant'altro) di allocazione, con l'ovvia eccezione deti tipi di dato LOB... paradossalmente, la definizione di tabella poteva eventualmenter richiedere allocazione teorica superiore alla pagina stessa, quindi l'istruzione CREATE TABLE xx ( id int PRIMARY KEY, colA varchar(8000), colB varchar(8000)); e' legittima malgrado generi un warning... verra' poi valutato al momento di effettivo utilizzo il problema di valicamento del limite stesso.. quindi sara' poi legittimo scrivere INSERT INTO xx VALUES (1, @valore_di_4000_caratteri,
@altro_valore_di_4000_caratteri); e tutte le combinazioni possibile, sempre che si rientri negli 8kb... in caso contrario verra' sollevata un'eccezione...
con SQL Server 2005 lo storage engine presenta una grande novita' permettendo ad ogni singola riga di eccedere il limite di pagina (stiamo sempre ovviamente escludendo i tipi LOB che gia' venivano gestiti diversamente)... rientra in questo concetto lo "stato" di "row overflow" che in definitiva consente completamente, nella stessa definizione di tabella precedentemente enunciata, una valorizzazione simile a INSERT INTO xx VALUES (1, @valore_di_8000_caratteri, @altro_valore_di_8000_caratteri); le "eccedenze" verrano archiviate in altrettante pagine come necessario, con lo stato di "row overflow" che verranno poi linkate alla pagina originaria... questa importante innovazione ha quindi permesso di estendere le potenzialita' di archiviazione consentendo di aumentare lo storage, ad esempio nel tipo di dato varchar, da un massimo come prima consentito di "8000" ad un massimo ora espresso in "MAX", che attualmente e' 2gb, e forse magari in futuro sara' aumentato...
saluti