Text og nText helvede her i sommervarmen :-)

Prøv at dæmpe antallet af point, så kan det være du bliver taget lidt mere seriøst!

:o)

Har du prøvet at køre din stored procedure i query analyzeren.
Det er for at finde ud af om din stored procedure fejler i SQL server eller i ASP.
Jeg har selv haft problemer med at trække tekst ud fra ntext felter.
Tjek det lige.

ha ha, det er første gang der er kommet klager over \"for mange points\" :-)

Ej, jeg har rodet med det i snart 14 dage, og jeg er ved at dø!

Det var lige før jeg ville smide et turkort til en glædespige, i puljen i stedet for points.
Men jeg var bange for at spørgsmålet ville blive lukket så :-)

ij>> Jeg arbejder hele tiden i Query analyseren. Og det virker fint når jeg converter mit nText felt til fx: convert(varchar(8000),txNews), men så får jeg KUN 8000/4000 tegn med :-(

:-)

Her er så lidt at læse.
Det viser sig at du skal hente værdien af feltet i flere omgange hvis det overstiger 4K.

Eval Database Columns with ntext Data Types
The Comment columns in the Activity, Location, and PersonActivity tables have an ntext data type and can store 1,073,741,823 characters or 2 gigabytes (GB) of data. The default column length for an ntext column is 16 characters. You cannot change this value because the column contains a 16-byte pointer to the location of the ntext data and not the data itself. The actual ntext value is not stored as part of the data; it is stored in a separate collection of data pages. The ntext data type (the Unicode text data type) has the following characteristics, which might affect your decision to specify this data type for a column:

An ntext column cannot be used in an ORDER BY clause. Because the Eval columns with ntext data types contain comments and notes, which by nature are more likely to be sentences than single words, no benefits are lost because you cannot sort on this column.
An ntext column with a large data value must be handled on a block-by-block basis. The database designers do not expect ntext columns in the Eval database to be more than 4,000 characters long and therefore the columns do not require special handling. Your application can use database APIs to read and write columns in a block-by-block fashion when ntext data values are long.
The ntext data type cannot be used for variables or parameters in stored procedures. The content of the Comment fields in the Eval database makes it unlikely that they will be used for variables or parameters, and this restriction does not affect the stored prodedures used by the PT application.
In addition, it is a good idea to define the table column that has an ntext data type as the last column in the table because any SELECT statement that retrieves this column requires that this column be last. When a table has more than one ntext field, place the ntext fields last. You can explicitly specify the order of the columns in the SELECT statement, regardless of the position of the ntext field in the column definitions. Converting a Recordset to XML in the Implementation section describes reading ntext data.

Du kan godt hente hele værdien i ASP, da det er ADO der styrer det.

ij>> Jeg er ikke så godt til Norsk :-)
MEn jeg læser lige på det i aften...

Hvis der er nogle som har kode eksempler, så er jeg rigtig rigtig tæt på at blive glad igen :-)

Jeg vil sige at det no er en dårlig idé at bruge en stored procedure til at hente Ntext felter, når du har ADO til at klare det for dig, og så lidt simpel ASP.
Gå dog ikke over åen efter vand.
Hvis du henter flere felter ud, er det en god idé at hente Ntext felter ud til sidst i din SQL statement i ASP.

Fair nok Lauge, den situation har vi vist alle været i :o) Men hvis glædespigen kommer i puljen, så tager jeg et aftenkursus i norsk - he he!

Kan se i dit andet spørgsmål, at du vil returnere dit ntext felt som en output parameter - hvorfor vil du dog det???

Du skal ikke bruge convert funktionen, da du jo gerne vil have hele dit tekstfelt ud, det får du ikke hvis du konverterer det til noget, som potentielt er kortere.

I øvrigt vil det jo nok hjælpe lidt, hvis vi ser hele din stored procedure, samt hvordan du kalder den. Altså noget kode!!!!

Jeg forstår ikke helt hvorfor noget kode skulle have interesse, for mit spørgsmål er jo \"bare\", hvordan henter jeg noget tekst(i et nText felt) ud af en msSQL server, gennem en Stored Procedures, gennem min ASP og ud i min kære browser :-)

Er jeg den eneste i verden der gene vil gøre det på denne måde, eller har I andre også prøvet og givet op? *GG*

Men her er noget kode hvis det har interesse:

Min Stored Procedures///////////////////////////////////////////////////

CREATE PROCEDURE sp_NyhedRetTjek

    @NewsId int,
    @txNyhed varchar(8000)      OUTPUT

As

    Declare @inForvaltning int
    Declare @inBrugerAfdeling int
    Declare @inMasterIdRelation int
   
-- Her kommer der så en masse SQL halløj som ikke har noget med  det at gøre
-- la la la la la la la la la la la
-- la la la la la la la la la la la
-- la la la la la la la la la la la
-- la la la la la la la la la la la
-- det slutter så hej :-)

-- og så kommer det sted hvor jeg MEGET gerne vil trække noget tekst ud af et Ntext felt :-)

Begin

Select @txManchet = convert(???????,txManchet)
    from tblNews where NewsId = @NewsId

End


GO


Her er min ASP kode ////////////////////////////////////////////////////////

Set cmdUpdate = Server.CreateObject(\"ADODB.Command\")


With cmdUpdate

    .ActiveConnection = sti
    .commandText = \"sp_NyhedRetTjek\"
    .commandType = adCmdStoredProc

\' Her er så fjernet en MASSE linjer da de virker som de skal og har ingen interesse

    .Parameters.Append .CreateParameter (\"@NewsId\", adInteger, adParamInput, , NewsID)

    .Parameters.Append .CreateParameter (\"@txNyhed\", adVarWChar, adParamOutput, 8000)



    .execute lngRecs, , adExecuteNoRecords

    txNyhed = .Parameters(\"@txNyhed\")

    \'Der bliver hentet en masse andre felter ud i variabler også.
    \' Men de kommer alle fra int og nChar felter, hvor jeg ingen problemer har :-)

End With
Set cmdUpdate = Nothing


Mon det bliver Jul i år?

Lauge

PS/ Ud i solen med jer drenge(efter i har løst fars opgave:-)

Jeg smed lige nogle flere points i puljen!

Tja, hvad kan man sige - at bruge en OUTPUT parameter er vel en måde - i så fald burde følgende virke:

Select @txManchet = convert(varchar(8000),txManchet)
    from tblNews where NewsId = @NewsId

Den første parameter i CONVERT er ganske simpelt den type, som man vil konvertere til. Jeg antager her, at txManchet er et felt i tblNews.

Du kan jo også lade din stored procedure returnere din text felt på helt normal vis. Dvs. fjern din OUTPUT parameter og lad din stored procedure slutte med:

select txManchet from tblNews where NewsID = @NewsID

Dermed fungerer din stored procedure i princippet som om, at du har kaldt ovenstående sql direkte fra ASP.

Håber dette giver dig et hint i den rigtige retning!

torbenkoch >>

Eksemplet:
Select @txManchet = convert(varchar(8000),txManchet)
    from tblNews where NewsId = @NewsId

virker jo fint nok, men problemet er jo så bare at den \"KUN\" henter de første 8000 tegn ud, eller KUN  de første 4000 fordi mit felt er et nTExt felt. Og jeg skal bruge MANGE flere tegn end dette, altså måske op til 100.000 eller 200.000 tegn (for at være sikker :-)

Dit andet ekspempel:
select txManchet from tblNews where NewsID = @NewsID

tro jeg ikke helt på at det virker(har ikke prøvet det endnu).
Fordi min Stored Procedures jo ved at feltet i DB er et nText felt, og så vil den IKKE lade mig smide indholdet ned i et nChar felt eller lig.

Lauge

Du kan være helt rolig, jeg har prøvet det - det virker. Hvorfor du tror at din stored procedure vil smide det ned i et nchar (e.li) felt, forstår jeg simpelthen ikke - den smider det jo ikke ned i nogle felter - den returnerer indholdet af feltet til dig.

Mit første eksempel skærer selvfølgelig de første 8000 tegn af, men eftersom din output parameter kun kan indeholde 8000 tegn, så er det jo en ganske fornuftig ting at gøre. Du kunne jo så vælge at lade din output parameter være ntext i stedet.... Så slipper du for at lave en konvertering....

torbenkoch>>Ææææ, kan man godt få lov til at difinere sit Output som nText felt?
Men hvis det stadigvæk KUN tillader 8000/4000 tegn, kan jeg ikke bruge det. Men jeg prøver det lige i løbet af dagen.

Men så er det gyldne spørgsmål så bare stadigvæk; hvordan får man så alt indholdet af et nText felt ud gennem en Stored Procedures????

Øv!

Det lader ikke til at nogen her på eksperten har prøvet det endnu :-)

Jeg kan sgutte huske om man kan bruge ntext som output - prøver det på et tidspunkt. Og selvfølgelig vil den så ikke skære af ved 4000 eller 8000 - men derimod ved 1000000 (ca.)...

Du kan også vælge min anden løsning, hvor du ikke skal bruge en output parameter. Den virker med garanti - så jo, der er faktisk en på eksperten, der har prøvet det.... ;-)

Man kan, både i SQL 7 og SQL 2000, godt lave en output parameter, der er af typen ntext. Så det burde ikke være det, der stopper dig.

Har du ellers fået afprøvet nogle af forslagene, så vi kan få spørgsmålet lukket??

torbenkoch>> Jeg har ikke tid til at prøve før weekenden.
Meeeeeen - jeg syntes heller ikke der er kommet vildt fede forslag! :-)

Da jeg jo er \"kode spasser\" så jeg gerne nogle kode forslag :-)

Det er jo 753 fede røde æbler vi snakker om her :-)

Jeg smider 9 æbler mere i kassen!

For 753 point må du jo forvente en færdig løsning, men så skal vi altså også have en lidt bedre \"kravspec\"... ;-)

753 point er jo selvfølgelig ikke det, der indbyder mest til at tage et spørgsmål alvorligt (som nævnt ovenfor), men ikke desto mindre er der dog kommet nogle løsningsforslag på \"bordet\", som kan anvendes. At få 753 point for vil være ret latterligt, men prøv med de sædvanlige 15, 30 eller 60, som passer bedre til spørgsmålets sværhedsgrad.

Men ellers held og lykke med det i weekenden!

Og nu er weekenden jo for længst gået - noget nyt?

skal man egentlig ikke bruge textptr, readtext etc. for at få mere end 8000 tegn med ud af et text, ntext, image felt.

Du kan da kigge i sql-server books online - jeg orker ik at forklare hvorn det virker her på eksperten!

Du har to problemer.
1. du definere en varchar i som parameter i dit dataobjekt. Varchar kan kun indeholde 8000 byte. I asp/vb kan en variant (adVariant) modtage en ntext.
2. Det er lidt besværligt at operere med nText en procedure, Det er betydeligt nemmere at lade disse mastodonter blive i tabellerne. Hvis du lader din procedure levere et recordset i stedet for en parameter, springer du elegant over dette problem.
Følgende kode levere en ntext til en variabel i VB. (det er nøjagtigt det samme i asp.)

CREATE PROCEDURE  dbo.z_testText  AS

set nocount on

CREATE TABLE #TextTest (ColA INT PRIMARY KEY, ColB TEXT)

INSERT INTO #TextTest
  VALUES( 1,
          \'Her står en masse  meget lang tekst. Op til flere sider ævl.\')

SELECT colB FROM #TextTest WHERE ColA = 1

drop table #TextTest

GO

Dette er koden der modtager i VB


Public Function TextText()
Dim Res As ADODB.Recordset
Dim cmditems As New ADODB.Command
Dim text


Set cmditems.ActiveConnection = CurrentProject.Connection
cmditems.CommandText = \"z_testText\"
cmditems.CommandType = adCmdStoredProc
cmditems.CommandTimeout = 15
Set rst = cmditems.Execute

text = rst!colb

End Function


Variablen text er af typen variant og kan ligesom ntext indeholde meget tekst.


Hvis du absolut vil lide med nText i din kode, skal du bruge READTEXT og WRITETEXT. Jeg ville  umiddelbart vælge den nemme løsning.