PHP: Opslaan van lange string in MS SQL Server database

[Marcel]

Hallo,

Heeft iemand enige suggesties?

Ik heb een hele lange string die een RTF document bevat. Deze RTF string wil
ik opslaan in een MS SQL database (in een image kolom van de tabel). Om
ruimte te besparen comprimeer ik deze string eerst. Daarna vervang ik de
qoutes in de gecomprimeerde data door dubbele quotes en voer ik addslashes
uit:

$SQL_archive = "INSERT INTO rtf_archief (PortaalIDPakket,Soort,Rtf) VALUES
('".$PortaalIDPakket."','PO','".str_replace("'","''",addslashes(gzcompress($
RTF2)))."')";

Dat gaat goed zo maar ik heb een probleem om de geinserte data uit de tabel
weer terug te toveren in de originele RTF string.

Misschien dom maar ik dacht van gewoon hetzelfde doen maar dan in omgekeerde
volgorde dus:

$RTFdecompressed = gzuncompress(stripslashes(str_replace("''","'",$RTF)));

Maar die vlieger gaat helaas niet op...

Heeft iemand hier een suggestie voor?

bedankt alvast!

Marcel

[Maarten Wierda]

Marcel wrote:

> Ik heb een hele lange string die een RTF document bevat. Deze RTF string wil
> ik opslaan in een MS SQL database (in een image kolom van de tabel).

Waarom wil je dit eigenlijk in je database opslaan?


--
Cheers, Maarten Wierda

"Teenage angst has paid off well, now I'm bored and old"

[Daniel Tryba]

Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
> Daarna vervang ik de qoutes in de gecomprimeerde data door dubbele
> quotes en voer ik addslashes uit:

Waarom beide? 1 van de 2 is maar nodig. Ik heb geen idee welke MSSQL
gebruikt (dacht ' -> '').

> Misschien dom maar ik dacht van gewoon hetzelfde doen maar dan in omgekeerde
> volgorde dus:
>
> $RTFdecompressed = gzuncompress(stripslashes(str_replace("''","'",$RTF)));

Je hoeft de terugconversie niet te doen. Stel de in te voeren string is
"All's well" moet dat geescaped worden naar "All\'s well" bij de insert.
Bij het uitlezen krijg je direct het orgineel terug.

--

Daniel Tryba

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> Ik heb een hele lange string die een RTF document bevat. Deze RTF string wil
>> ik opslaan in een MS SQL database (in een image kolom van de tabel).
>
> Waarom wil je dit eigenlijk in je database opslaan?

Waarom niet? Ik gebruik zelf een mysql database voor sessies (en prop de
sessie daar ge-compressed in), dat gaat sneller dan in files.

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

>>>Ik heb een hele lange string die een RTF document bevat. Deze RTF string wil
>>>ik opslaan in een MS SQL database (in een image kolom van de tabel).
>>
>>Waarom wil je dit eigenlijk in je database opslaan?
>
> Waarom niet? Ik gebruik zelf een mysql database voor sessies (en prop de
> sessie daar ge-compressed in), dat gaat sneller dan in files.

Voor sessies begrijp ik het wel. Ik dacht dat het hier om een
RTF-document ging. Dat hoef je toch niet in een database op te slaan?

--
Cheers, Maarten Wierda

"Teenage angst has paid off well, now I'm bored and old"

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
[RTF]
>>>Waarom wil je dit eigenlijk in je database opslaan?
>>
>> Waarom niet? Ik gebruik zelf een mysql database voor sessies (en prop de
>> sessie daar ge-compressed in), dat gaat sneller dan in files.
>
> Voor sessies begrijp ik het wel.

Ik zie persoonlijk weinig verschil. Beide zijn tekststrings, de RTF
heeft het voordeel dat het vrijwel readonly is.

> Ik dacht dat het hier om een RTF-document ging. Dat hoef je toch niet
> in een database op te slaan?

Simpel voorbeeld waarom je het wel zou willen: stel je hebt meer dan 1
machine, hoe wil je het dan doen? Backups gaat ook wat handiger...

--

Daniel Tryba

[Marcel]

"Daniel Tryba" <news_nl.internet.www.server-side@canopus.nl> schreef in
bericht news:br9qsu$7me$1@news.tue.nl...
> Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
> > Daarna vervang ik de qoutes in de gecomprimeerde data door dubbele
> > quotes en voer ik addslashes uit:
>
> Waarom beide? 1 van de 2 is maar nodig. Ik heb geen idee welke MSSQL
> gebruikt (dacht ' -> '').
>
> > Misschien dom maar ik dacht van gewoon hetzelfde doen maar dan in
omgekeerde
> > volgorde dus:
> >
> > $RTFdecompressed =
gzuncompress(stripslashes(str_replace("''","'",$RTF)));
>
> Je hoeft de terugconversie niet te doen. Stel de in te voeren string is
> "All's well" moet dat geescaped worden naar "All\'s well" bij de insert.
> Bij het uitlezen krijg je direct het orgineel terug.
>
> --

Bedankt voor je antwoord maar dit gaat volgens mij wel op voor MySQL maar
niet voor MS SQL..

Marcel

[Marcel]

"Maarten Wierda" <moart3nAT@chello.nl> schreef in bericht
news:br9oco$1nkr$4@nl-news.euro.net...
> Marcel wrote:
>
> > Ik heb een hele lange string die een RTF document bevat. Deze RTF string
wil
> > ik opslaan in een MS SQL database (in een image kolom van de tabel).
>
> Waarom wil je dit eigenlijk in je database opslaan?
>
>
> --

Omdat het zeer veel rtf's betreft die aan verschillende namen verbonden
dienen te worden...

Marcel

[Daniel Tryba]

Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
[integrale kwoot]
>> > Daarna vervang ik de qoutes in de gecomprimeerde data door dubbele
>> > quotes en voer ik addslashes uit:
>>
>> Waarom beide? 1 van de 2 is maar nodig. Ik heb geen idee welke MSSQL
>> gebruikt (dacht ' -> '').
>>
>> > Misschien dom maar ik dacht van gewoon hetzelfde doen maar dan in
> omgekeerde
>> > volgorde dus:
>> >
>> > $RTFdecompressed =
> gzuncompress(stripslashes(str_replace("''","'",$RTF)));
>>
>> Je hoeft de terugconversie niet te doen. Stel de in te voeren string is
>> "All's well" moet dat geescaped worden naar "All\'s well" bij de insert.
>> Bij het uitlezen krijg je direct het orgineel terug.
[/integrale kwoot]

> Bedankt voor je antwoord maar dit gaat volgens mij wel op voor MySQL maar
> niet voor MS SQL..

Kan je iets duidelijker zijn? Bedoel je het inserten of het uitlezen (of
beide)?

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

[RTF]

>>>>Waarom wil je dit eigenlijk in je database opslaan?

<snip>

> Ik zie persoonlijk weinig verschil. Beide zijn tekststrings, de RTF
> heeft het voordeel dat het vrijwel readonly is.
>
>>Ik dacht dat het hier om een RTF-document ging. Dat hoef je toch niet
>>in een database op te slaan?
>
> Simpel voorbeeld waarom je het wel zou willen: stel je hebt meer dan 1
> machine, hoe wil je het dan doen? Backups gaat ook wat handiger...

Dit is toch vergelijkbaar met het opslaan van plaatjes in je database?
Als je 1 machine hebt kun je toch even goed backuppen? En je kunt het
bestand bewerken zonder het eerst uit de database te moeten halen. En je
database wordt niet ontzettend groot. Of sla ik nu volledig de plank mis?

--
Cheers, Maarten Wierda (af en toe nog een redelijke n00b)
cp: Mondo Generator - Day I Die

"Teenage angst has paid off well, now I'm bored and old"

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
>>>Ik dacht dat het hier om een RTF-document ging. Dat hoef je toch niet
>>>in een database op te slaan?
>>
>> Simpel voorbeeld waarom je het wel zou willen: stel je hebt meer dan 1
>> machine, hoe wil je het dan doen? Backups gaat ook wat handiger...
>
> Dit is toch vergelijkbaar met het opslaan van plaatjes in je database?

Huh? Je kan plaatjes zonder problemen opslaan in een database, het is
zaak dat je bij het tonen de goede headers meegeeft en bij request goed
kijkt of het een conditionele get is. Doe je dat dan is er geen extra
nadeel dan de verschillen die je ondervindt tussen dynamische urls en
statische urls.

> Als je 1 machine hebt kun je toch even goed backuppen?

Ik stel juist dat je meer dan 1 machine hebt, de database is dan het
centrale punt om te backuppen en om up-to-date te houden, je hebt geen
zelfde gegevens op verschillende plekken staan en er kan dus niets out
of sync zijn.

> En je kunt het bestand bewerken zonder het eerst uit de database te
> moeten halen.

Maar hoevaak wordt er iets gewijzigt, het opslaan van eenmalige data is
onzin ongeacht van het opslag medium.

> En je database wordt niet ontzettend groot.

Daar ligt een database niet wakker van (mits je structuur natuurlijk
goed is).

> Of sla ik nu volledig de plank mis?

Je hebt wel gelijk, maar je vertelt nog steeds niet wat nu het bezwaar
is tegen bestanden in een database. Heb je bv als eens met een
gigantische directory zitten stoeien, een database is dan toch echt wat
sneller.

--

Daniel Tryba

[Marcel]

"Daniel Tryba" <news_nl.internet.www.server-side@canopus.nl> schreef in
bericht news:bra059$98g$1@news.tue.nl...
> Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
> [integrale kwoot]
> >> > Daarna vervang ik de qoutes in de gecomprimeerde data door dubbele
> >> > quotes en voer ik addslashes uit:
> >>
> >> Waarom beide? 1 van de 2 is maar nodig. Ik heb geen idee welke MSSQL
> >> gebruikt (dacht ' -> '').
> >>
> >> > Misschien dom maar ik dacht van gewoon hetzelfde doen maar dan in
> > omgekeerde
> >> > volgorde dus:
> >> >
> >> > $RTFdecompressed =
> > gzuncompress(stripslashes(str_replace("''","'",$RTF)));
> >>
> >> Je hoeft de terugconversie niet te doen. Stel de in te voeren string is
> >> "All's well" moet dat geescaped worden naar "All\'s well" bij de
insert.
> >> Bij het uitlezen krijg je direct het orgineel terug.
> [/integrale kwoot]
>
> > Bedankt voor je antwoord maar dit gaat volgens mij wel op voor MySQL
maar
> > niet voor MS SQL..
>
> Kan je iets duidelijker zijn? Bedoel je het inserten of het uitlezen (of
> beide)?
>

Het inserten lukt, het selecten ook.... maar om daarna van de opgehaalde
data weer de originele rtf string te maken gaat niet goed....

[Maarten Wierda]

Daniel Tryba wrote:

>>>>Ik dacht dat het hier om een RTF-document ging. Dat hoef je toch niet
>>>>in een database op te slaan?
>>>
>>>Simpel voorbeeld waarom je het wel zou willen: stel je hebt meer dan 1
>>>machine, hoe wil je het dan doen? Backups gaat ook wat handiger...
>>
>>Dit is toch vergelijkbaar met het opslaan van plaatjes in je database?
>
> Huh?

As in binaire bestanden.

> Je kan plaatjes zonder problemen opslaan in een database,

<snip hoe dat gaat>

Ik weet dat je plaatjes kunt opslaan in een database, maar ik zie het
voordeel er niet van in. Zie
<http://www.yapf.net/faq.php?cmd=viewitem&itemid=621>. Of heb jij goede
tegenargumenten?

>>Als je 1 machine hebt kun je toch even goed backuppen?
>
> Ik stel juist dat je meer dan 1 machine hebt,

Verkeerd gelezen dus... sorry :)

> de database is dan het
> centrale punt om te backuppen en om up-to-date te houden, je hebt geen
> zelfde gegevens op verschillende plekken staan en er kan dus niets out
> of sync zijn.

Dat is wel handig. Maar dit kan toch ook zonder database?

>>En je kunt het bestand bewerken zonder het eerst uit de database te
>>moeten halen.
>
> Maar hoevaak wordt er iets gewijzigt,

Tsja, dat weet je nooit. Het zou echter wel kunnen gebeuren.

>>En je database wordt niet ontzettend groot.
>
> Daar ligt een database niet wakker van (mits je structuur natuurlijk
> goed is).

True.

>>Of sla ik nu volledig de plank mis?
>
> Je hebt wel gelijk, maar je vertelt nog steeds niet wat nu het bezwaar
> is tegen bestanden in een database. Heb je bv als eens met een
> gigantische directory zitten stoeien, een database is dan toch echt wat
> sneller.

Nog niet ;) Maar wat niet is kan nog komen, misschien zal ik ooit inzien
waarom het opslaan in een database beter is.

--
Cheers, Maarten Wierda
cp: Dinosaur Jr - Puke + Cry

"Teenage angst has paid off well, now I'm bored and old"

[Daniel Tryba]

Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
>> Kan je iets duidelijker zijn? Bedoel je het inserten of het uitlezen (of
>> beide)?
>>
>
> Het inserten lukt, het selecten ook.... maar om daarna van de opgehaalde
> data weer de originele rtf string te maken gaat niet goed....

Inserten op welke manier?
De oplossing is simepl: maak test scripts en controleer. Dus niet meteen
met een hele rtf maar een simpele test string, iets met ' en \ erin.
Post hier de testcases en wellicht kan men je beter helpen, je komt nu
niet verder dan te vertellen dat "het niet werkt".

--

Daniel Tryba

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
>>>Dit is toch vergelijkbaar met het opslaan van plaatjes in je database?
>>
>> Huh?
>
> As in binaire bestanden.

Wat is het verschil tussen binarie en text? IMHO is er geen enkel
verschil. Immers wat is tekst? Beperk je dat tot ascii, tot 8 bit dingen
als iso-8859-x of zullen we meteen maar voor multibyte unicode gaan?

>> Je kan plaatjes zonder problemen opslaan in een database,
>
> <snip hoe dat gaat>
>
> Ik weet dat je plaatjes kunt opslaan in een database, maar ik zie het
> voordeel er niet van in. Zie
> <http://www.yapf.net/faq.php?cmd=viewitem&itemid=621>. Of heb jij goede
> tegenargumenten?

Volgens mij stond er in het weggeknipte gedeelte dat als je het goed
doet dat een bestand in een database geen extra nadelen heeft dan
dynamische content vs. statische content. En dat wordt op bovenstaande
URL ook verkondigt
<q>
Met andere woorden, je kunt data uit een database _alleen_ via een
script ophalen, terwijl je een bestand op disk altijd rechtstreeks via
bv een IMG tag kunt aanspreken. Dat scheelt nogal wat snelheid.
</q>

Veder begint het verhaal met 'Het klinkt heel erg handig, nooit meer
fopen(), nooit meer fread() etc...'. Dit past totaal niet in de rest van
het verhaal waar juist gestreden word tegen het processesn van content in
een sss als je dat ook aan de webserver kan overlaten.

Een leuk stukje:
<q>
Als je ze index pagina ophaalt worden er dus 9 scripts opgestart om de
plaatjes op te halen (uitvoer van PHP scripts wordt in principe niet
gecached, dus die scripts draaien altijd). Samen met het script dat de
indexpagina zelf maakt heb je dan dus al 10 scripts nodig voor 1 pagina.
Dus als je vijf pageviews tegelijk krijgt dan worden er 50 scripts
gedraaid die alle 50 een query naar de database doen. Staan er 12
plaatjes op je index dan worden dat er 5*16 = 80. Worden het 10 mensen
dan zit je al op 160, twee keer de standaard waarde van mysql. En met
zoveel gelijktijdige queries wordt mysql al snel traag.
</q>

Het begint al met dat de uitvoer van php paginas niet wordt gecached,
zeker in het geval van statische plaatjes is dat natuurlijk heel dom en
zonde van je processor tijd. Sla dus ook de last-modified tijd op en
stuur die mee, browsers zullen dan vragen of het plaatje veranderd is en
dat scheelt het overpompen van de data.

Als je je webserver goed configureerd zullen meerdere requests over de
zelfde connection gedaan worden (connection keep-alive). Het aantal
connecties ligt dan in de zelfde orde grote als het aantal bezoekers.

Een mysql database die ik in productie heb staan heeft z'n connection
limit op 1000 staan, op de drukke momenten (zo'n 400 concurrent sessies)
staan er zo'n 100 connecties daadwerkelijk open (persistant connecties).
Op het drukste moment van vandaag (9:40) was de load '0.26 0.28 0.17'
en was de machine 92% idle met 430 actieve sessies. Dat is toch iets
meer dan het in het ramplenplan beschreven 30 gelijktijdige bezoekers.
Nou moet ik wel toegeven dat ik daarvoor 2 frontend machines tot mijn
beschikking heb (1 staat nog reserve), maar de load kan ook door 1
frontend worden geserveerd, de 2de staat er tbv bereikbaarheid.

Een testprogje wijst uit dat de het opentrekken van 1000 connecties
resulteerde in het falen van de client (door z'n max processes heen), de
server gebruikte op dat moment zo'n 500Mb, maar als je 1.5Gb over hebt
als diskcache dan is dat absoluut geen ramp.

De toegevoegde waarde van de centrale database, oa:
-failover, er staat geen (user)data op de frontends het installeren
van een frontend is niet meer dan het deployen van de code en in
de loadbalancer mikken.
-de database wordt gerepliceerd, als die machine afbrand staat er nog
eentje naast met de zelfde data (wellicht dat je een paar seconden
mist)
-er is maar 1 datastore te archieveren.

Toegevoegde waarde van data geserveerd door sss is oa de extra
access-control laag die je kan toevoegen en veel meer data bij de data
zelf kan opslaan dan het filesystem biedt.

>> de database is dan het centrale punt om te backuppen en om up-to-date
>> te houden, je hebt geen zelfde gegevens op verschillende plekken
>> staan en er kan dus niets out of sync zijn.
>
> Dat is wel handig. Maar dit kan toch ook zonder database?

You tell me.

>>>En je kunt het bestand bewerken zonder het eerst uit de database te
>>>moeten halen.
>>
>> Maar hoevaak wordt er iets gewijzigt,
>
> Tsja, dat weet je nooit. Het zou echter wel kunnen gebeuren.

Tuurlijk kan dat, maar zelfs indien het enkele keren per dag wijzigt,
wat is dan het probleem? Bij de manuele handeling van wijzigen is het
ophalen en opslaan maar 2 stappen extra.

>> Je hebt wel gelijk, maar je vertelt nog steeds niet wat nu het
>> bezwaar is tegen bestanden in een database. Heb je bv als eens met
>> een gigantische directory zitten stoeien, een database is dan toch
>> echt wat sneller.
>
> Nog niet ;) Maar wat niet is kan nog komen, misschien zal ik ooit
> inzien waarom het opslaan in een database beter is.

Ik zeg niet dat het beter is, ik zeg dat het geen probleem is en dat het
extra mogelijkheden met zich meebrengt. Ik kan niets anders zeggen dan:
It works for me.

Overigens is PHP niet de meest geschikte omgeving voor die soort
spulletjes, connection pooling ontbreekt bv.

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

> Wat is het verschil tussen binarie en text? IMHO is er geen enkel
> verschil. Immers wat is tekst? Beperk je dat tot ascii, tot 8 bit dingen
> als iso-8859-x of zullen we meteen maar voor multibyte unicode gaan?

Hmm, ok. Klopt.

>>>Je kan plaatjes zonder problemen opslaan in een database,
>>
>><snip hoe dat gaat>
>>
>>Ik weet dat je plaatjes kunt opslaan in een database, maar ik zie het
>>voordeel er niet van in. Zie
>><http://www.yapf.net/faq.php?cmd=viewitem&itemid=621>. Of heb jij goede
>>tegenargumenten?
>
> Volgens mij stond er in het weggeknipte gedeelte dat als je het goed
> doet dat een bestand in een database geen extra nadelen heeft dan
> dynamische content vs. statische content. En dat wordt op bovenstaande
> URL ook verkondigt
> <q>
> Met andere woorden, je kunt data uit een database _alleen_ via een
> script ophalen, terwijl je een bestand op disk altijd rechtstreeks via
> bv een IMG tag kunt aanspreken. Dat scheelt nogal wat snelheid.
> </q>
>
> Veder begint het verhaal met 'Het klinkt heel erg handig, nooit meer
> fopen(), nooit meer fread() etc...'. Dit past totaal niet in de rest van
> het verhaal waar juist gestreden word tegen het processesn van content in
> een sss als je dat ook aan de webserver kan overlaten.
>
> Een leuk stukje:
> <q>
> Als je ze index pagina ophaalt worden er dus 9 scripts opgestart om de
> plaatjes op te halen (uitvoer van PHP scripts wordt in principe niet
> gecached, dus die scripts draaien altijd). Samen met het script dat de
> indexpagina zelf maakt heb je dan dus al 10 scripts nodig voor 1 pagina.
> Dus als je vijf pageviews tegelijk krijgt dan worden er 50 scripts
> gedraaid die alle 50 een query naar de database doen. Staan er 12
> plaatjes op je index dan worden dat er 5*16 = 80. Worden het 10 mensen
> dan zit je al op 160, twee keer de standaard waarde van mysql. En met
> zoveel gelijktijdige queries wordt mysql al snel traag.
> </q>
>
> Het begint al met dat de uitvoer van php paginas niet wordt gecached,
> zeker in het geval van statische plaatjes is dat natuurlijk heel dom en
> zonde van je processor tijd. Sla dus ook de last-modified tijd op en
> stuur die mee, browsers zullen dan vragen of het plaatje veranderd is en
> dat scheelt het overpompen van de data.
>
> Als je je webserver goed configureerd zullen meerdere requests over de
> zelfde connection gedaan worden (connection keep-alive). Het aantal
> connecties ligt dan in de zelfde orde grote als het aantal bezoekers.
>
> Een mysql database die ik in productie heb staan heeft z'n connection
> limit op 1000 staan, op de drukke momenten (zo'n 400 concurrent sessies)
> staan er zo'n 100 connecties daadwerkelijk open (persistant connecties).
> Op het drukste moment van vandaag (9:40) was de load '0.26 0.28 0.17'
> en was de machine 92% idle met 430 actieve sessies. Dat is toch iets
> meer dan het in het ramplenplan beschreven 30 gelijktijdige bezoekers.
> Nou moet ik wel toegeven dat ik daarvoor 2 frontend machines tot mijn
> beschikking heb (1 staat nog reserve), maar de load kan ook door 1
> frontend worden geserveerd, de 2de staat er tbv bereikbaarheid.
>
> Een testprogje wijst uit dat de het opentrekken van 1000 connecties
> resulteerde in het falen van de client (door z'n max processes heen), de
> server gebruikte op dat moment zo'n 500Mb, maar als je 1.5Gb over hebt
> als diskcache dan is dat absoluut geen ramp.
>
> De toegevoegde waarde van de centrale database, oa:
> -failover, er staat geen (user)data op de frontends het installeren
> van een frontend is niet meer dan het deployen van de code en in
> de loadbalancer mikken.
> -de database wordt gerepliceerd, als die machine afbrand staat er nog
> eentje naast met de zelfde data (wellicht dat je een paar seconden
> mist)
> -er is maar 1 datastore te archieveren.
>
> Toegevoegde waarde van data geserveerd door sss is oa de extra
> access-control laag die je kan toevoegen en veel meer data bij de data
> zelf kan opslaan dan het filesystem biedt.

<snip>

>>>>En je kunt het bestand bewerken zonder het eerst uit de database te
>>>>moeten halen.
>>>
>>>Maar hoevaak wordt er iets gewijzigt,
>>
>>Tsja, dat weet je nooit. Het zou echter wel kunnen gebeuren.
>
> Tuurlijk kan dat, maar zelfs indien het enkele keren per dag wijzigt,
> wat is dan het probleem? Bij de manuele handeling van wijzigen is het
> ophalen en opslaan maar 2 stappen extra.
>
>>>Je hebt wel gelijk, maar je vertelt nog steeds niet wat nu het
>>>bezwaar is tegen bestanden in een database. Heb je bv als eens met
>>>een gigantische directory zitten stoeien, een database is dan toch
>>>echt wat sneller.
>>
>>Nog niet ;) Maar wat niet is kan nog komen, misschien zal ik ooit
>>inzien waarom het opslaan in een database beter is.
>
> Ik zeg niet dat het beter is, ik zeg dat het geen probleem is en dat het
> extra mogelijkheden met zich meebrengt. Ik kan niets anders zeggen dan:
> It works for me.

Bedankt voor je duidelijke verhaal. Ik zal het zeker nog een keer wat
uitgebreider bestuderen. In ieder geval is alles weer een stukje
duidelijker.

> Overigens is PHP niet de meest geschikte omgeving voor die soort
> spulletjes, connection pooling ontbreekt bv.

Check.

--
Cheers, Maarten Wierda

"Teenage angst has paid off well, now I'm bored and old"

[Marcel]

"Daniel Tryba" <news_nl.internet.www.server-side@canopus.nl> schreef in
bericht news:bra3gr$aff$2@news.tue.nl...
> Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
> >> Kan je iets duidelijker zijn? Bedoel je het inserten of het uitlezen
(of
> >> beide)?
> >>
> >
> > Het inserten lukt, het selecten ook.... maar om daarna van de opgehaalde
> > data weer de originele rtf string te maken gaat niet goed....
>
> Inserten op welke manier?
> De oplossing is simepl: maak test scripts en controleer. Dus niet meteen
> met een hele rtf maar een simpele test string, iets met ' en \ erin.
> Post hier de testcases en wellicht kan men je beter helpen, je komt nu
> niet verder dan te vertellen dat "het niet werkt".
>
> --

Beste Daniel,

In mijn eerste posting staat het insert statement, in diezelfde posting
staat hoe ik de string die ik uit de database haal weer terug probeer te
krijgen in zijn originele vorm.

Maar laat maar zitten, ik zoek zelf wel verder, ik heb niet echt het gevoel
dat jij of iemand in deze nieuwsgroep het weet.

Maar evengoed bedankt!

Marcel

[Daniel Tryba]

Marcel <neegeenspam@hotentottententententoonstellingen.nl> wrote:
> In mijn eerste posting staat het insert statement, in diezelfde posting
> staat hoe ik de string die ik uit de database haal weer terug probeer te
> krijgen in zijn originele vorm.

Ik vermelde op deze posting wat mijn gedachten waren (namelijk dat je
het niet goed doet).

> Maar laat maar zitten, ik zoek zelf wel verder, ik heb niet echt het gevoel
> dat jij of iemand in deze nieuwsgroep het weet.

Dat is de instelling waarmee je hulp krijgt. Pak het probleem nu maar
eens op de XP manier aan en je weet binnen 3 testcases wat de oplossing
is voor je probleem. Als je van mij een hapklare oplossing wilt zul je
me eerst moeten voorzien van de benodigde software.

--

Daniel Tryba