"Andrew Thompson" <andrew64@bigNOSPAMpond.com> wrote in message news:<wN2Cb.48704$aT.40380@news-server.bigpond.net.au>...

[snip]

> As it happens, I don't care - you are not
> paying me enough.
>
> And in future, please do not cross-post
> so widely. You are not that important,
> trust me.
>

[snip]

>
> Good for you. Just how do you expect
> others to debug them for you? Telepathy?
>

Geez, could you be any more of a jackass?


[snip]

> >..Any solutions/help/nudges in the right
> > direction are greatly appreciated
>
> The ones I have to give, you've got..

After all that you can't even help.
And in future, please do not post if
you can't help. You are not that important,
trust me.

"Ryan Stewart" <zaphod@no.texas.spam.net> wrote in
news:TIadnSzOONjJMkWiRTvUrg@texas.net:

> and it works for small files,
> but larger ones ... give an
> error saying that the data is too large for the field.
> Any solutions/help/nudges in the right
> direction are greatly appreciated

As a workaround store big files as several slices of 4k (or whatever the
limit is) (maybe in a new table - with a slice-# as part of the key) and
reassemble them at retrieval time.

"moose" <sky_diver_@excite.com> wrote in message
news:5725cfe.0312180606.7cd341fb@posting.google.co m...
> "Andrew Thompson" <andrew64@bigNOSPAMpond.com> wrote in message
news:<wN2Cb.48704$aT.40380@news-server.bigpond.net.au>...
>
> [snip]
>
> > As it happens, I don't care - you are not
> > paying me enough.
> >
> > And in future, please do not cross-post
> > so widely. You are not that important,
> > trust me.
> >
>
> [snip]
>
> >
> > Good for you. Just how do you expect
> > others to debug them for you? Telepathy?
> >
>
> Geez, could you be any more of a jackass?
>
>
> [snip]
>
> > >..Any solutions/help/nudges in the right
> > > direction are greatly appreciated
> >
> > The ones I have to give, you've got..
>
> After all that you can't even help.

Did you miss..
"Maybe you are 'getting' the data rather than
posting it. ..but.."
[ As it turns out, I was completely wrong. ]

> And in future, please do not post if
> you can't help. You are not that important,
> trust me.

:)

So let's sum this up.

I offered the OP 1 (albeit wrong) suggestion
23 hrs prior to a deadline that lay (presumedly)
within 24 hrs.

You offered the OP the above (which I did not
trim a character of), that is, nothing at all - some
120+ hours past the deadline.

That would seem to make you as useful as
an udder on a male moose, no?

Funny, your math doesn't add up.
I never critisized the OP or offered any help to the OP.
That was YOU, in your astounding arrogance.

I stand by my first statement regarding your behavior.
What a jackass!

"Andrew Thompson" <andrew64@bigNOSPAMpond.com> wrote in message news:<ZcjEb.57390$aT.24654@news-server.bigpond.net.au>...
> So let's sum this up.
>
> I offered the OP 1 (albeit wrong) suggestion
> 23 hrs prior to a deadline that lay (presumedly)
> within 24 hrs.
>
> You offered the OP the above (which I did not
> trim a character of), that is, nothing at all - some
> 120+ hours past the deadline.
>
> That would seem to make you as useful as
> an udder on a male moose, no?

This is cool stuff, Is there anyway to implement a sort of Network
File System using Oracle using blobs. The question is, will this kill
the oracle server?
Will the performance being in better using File I/O for example using
servlets?

I would like to try it but I hate to mess up our server for doing so.
Are there any benchmarks?


Thomas Schodt <news0310@xenoc.$DEMON.co.uk> wrote in message news:<Xns945592D0EE3A4xenoc@158.152.254.254>...
> "Ryan Stewart" <zaphod@no.texas.spam.net> wrote in
> news:TIadnSzOONjJMkWiRTvUrg@texas.net:
>
> > and it works for small files,
> > but larger ones ... give an
> > error saying that the data is too large for the field.
> > Any solutions/help/nudges in the right
> > direction are greatly appreciated
>
> As a workaround store big files as several slices of 4k (or whatever the
> limit is) (maybe in a new table - with a slice-# as part of the key) and
> reassemble them at retrieval time.

bigbinc wrote:

> This is cool stuff,

"Really idiotic" is the expression I'd use.

> Is there anyway to implement a sort of Network
> File System using Oracle using blobs. The question is, will this kill
> the oracle server?

If used even halfway intensively, yes.

> Will the performance being in better using File I/O for example using
> servlets?

Yes. A LOT better. Easily 100 times better. It's exactly the thing that
modern file systems try so hard to prevent and CS teaches you to avoid like
the plague: fragment big files into small chunks and scatter them all over
the place so that the HD's latency completely dominates its transfer speed.

"bigbinc" <bigbinc@hotmail.com> wrote in message
news:d1b33313.0401081044.27ac8238@posting.google.c om...
*made bottom post*
> Thomas Schodt <news0310@xenoc.$DEMON.co.uk> wrote in message
news:<Xns945592D0EE3A4xenoc@158.152.254.254>...
> > "Ryan Stewart" <zaphod@no.texas.spam.net> wrote in
> > news:TIadnSzOONjJMkWiRTvUrg@texas.net:
> >
> > > and it works for small files,
> > > but larger ones ... give an
> > > error saying that the data is too large for the field.
> > > Any solutions/help/nudges in the right
> > > direction are greatly appreciated
> >
> > As a workaround store big files as several slices of 4k (or whatever the
> > limit is) (maybe in a new table - with a slice-# as part of the key) and
> > reassemble them at retrieval time.
> This is cool stuff, Is there anyway to implement a sort of Network
> File System using Oracle using blobs. The question is, will this kill
> the oracle server?
> Will the performance being in better using File I/O for example using
> servlets?
>
> I would like to try it but I hate to mess up our server for doing so.
> Are there any benchmarks?

That's pretty much what I was/am doing: making a file-sharing system. We
managed to get around the 4k limit by bypassing certain things and manually
inserting the file data into the database.

Michael Borgwardt <brazil@brazils-animeland.de> wrote in message news:<btk8td$84qki$1@ID-161931.news.uni-berlin.de>...
> bigbinc wrote:
>
> > This is cool stuff,
>
> "Really idiotic" is the expression I'd use.

You are kidding me right, A filesystem is basically a database full
of file nodes.

If you are dealing in a one OS, one machine fine, standard file access
is great. If you are dealing with heterogenous networks, where NFS
is not available, then a Databased filesystem may in fact be the only
way to go.

See oracle internet filesystem.

[url]http://otn.oracle.com/documentation/ifs_arch.html[/url]

Plus the fact, where is your data and performance stats, as you very
well know to say an approach in the computer industry is completely
idiotic, is idiotic.

"bigbinc" <bigbinc@hotmail.com> wrote in message
news:d1b33313.0401081514.22b13c31@posting.google.c om...
> Michael Borgwardt <brazil@brazils-animeland.de> wrote in message
news:<btk8td$84qki$1@ID-161931.news.uni-berlin.de>...
> > bigbinc wrote:
> >
> > > This is cool stuff,
> >
> > "Really idiotic" is the expression I'd use.
>
> You are kidding me right, A filesystem is basically a database full
> of file nodes.
>
> If you are dealing in a one OS, one machine fine, standard file access
> is great. If you are dealing with heterogenous networks, where NFS
> is not available, then a Databased filesystem may in fact be the only
> way to go.
>
> See oracle internet filesystem.
>
> [url]http://otn.oracle.com/documentation/ifs_arch.html[/url]
>
> Plus the fact, where is your data and performance stats, as you very
> well know to say an approach in the computer industry is completely
> idiotic, is idiotic.

I think what he was referring to was the idea of breaking the files into
tiny chunks. Essentially, that would be purposely fragmenting the database.
And with a maximum fragment size of 4k, that would be really bad.

"Ryan Stewart" <zaphod@no.texas.spam.net> wrote in message news:<EKednXiwWOlJeGCiU-KYlg@texas.net>...
> "bigbinc" <bigbinc@hotmail.com> wrote in message
> news:d1b33313.0401081514.22b13c31@posting.google.c om...
> > Michael Borgwardt <brazil@brazils-animeland.de> wrote in message
> news:<btk8td$84qki$1@ID-161931.news.uni-berlin.de>...
> > > bigbinc wrote:
> > >
> > > > This is cool stuff,
> > >
> > > "Really idiotic" is the expression I'd use.
> >
> > You are kidding me right, A filesystem is basically a database full
> > of file nodes.
> >
> > If you are dealing in a one OS, one machine fine, standard file access
> > is great. If you are dealing with heterogenous networks, where NFS
> > is not available, then a Databased filesystem may in fact be the only
> > way to go.
> >
> > See oracle internet filesystem.
> >
> > [url]http://otn.oracle.com/documentation/ifs_arch.html[/url]
> >
> > Plus the fact, where is your data and performance stats, as you very
> > well know to say an approach in the computer industry is completely
> > idiotic, is idiotic.
>
> I think what he was referring to was the idea of breaking the files into
> tiny chunks. Essentially, that would be purposely fragmenting the database.
> And with a maximum fragment size of 4k, that would be really bad.


of course, sorry.