Hello Frank,

Am Dienstag, den 02.09.2008, 10:24 +0200 schrieb Frank Schönheit - Sun
Microsystems Germany:
> Hi Marc,
> 
> > I hope your workload will lower soon. In fact the statement "I'll file
> > an issue ..." is part of the citation. ;)
> 
> Oh ... which also means the other part of the citation wasn't mine -
> doh, I knew that was too profound for that ...
> 
> > But I'd take that task if I am sure what to write.
> 
> Thanks.
> 
> > Is it a limit or a lenght for:
> > 
> >    Form.Columns.getByName("").setBinarySream()
> >    aka ResultSet.get/setAnything.setBinaryStream()
> > 
> >    Form.Columns.getByName("").updateBinaryStream()
> >    aka ResultSet.get/setAnything.updateBinaryStream()
> > 
> >    css.sdbc.XParameter.setBinaryStream()
> > 
> > ?
> 
> I'd say it should be a limit for all of those.

Okay.

> > And I'll try again:
> > 
> > Does the last of those three (or all at best) need a stream implementing
> > css.io.XSeekable besides the XInputStream/XOutputSream interface?
> 
> None of those should need it. All implementations I found try to read as
> much bytes as indicated by the Length parameter.
> 
> Now that I looked up the implementations, again ... most of them even
> seem to silently ignore (implicitly, by using XInputStream::readBytes,
> which also does so) when there were less bytes than specified. The only
> exception is the ODBC bridge, whose setBinaryStream in fact throws an
> exception if it cannot read the specified number.
> 
> > The same is true for the ComponentLoader (not Documentloader) for input
> > streams, which is why people have to implement a stream wrapper offering
> > both interfaces (XInputStream & XSeekable).
> > 
> > Since my experiments handing over an input stream to a XParameter are
> > all blocking except when a dbase db is used as backend this could be the
> > problem. Or the "length" argument is biting back ...
> 
> What exactly do you mean with "are all blocking"? Does the call not return?

When I use "XParameter.setBinaryStream()" the Office goes into "no
display any more"-mode. Using top on FreeBSD I can see the process being
in in "poll"-mode. Looks like there is some synchronization issue or I'm
doing something wrongly.

On Win32 the behaviour is the same, in all cases there is no CPU load,
the office only doesn't do anything including refreshing the display.

I was trying to use a css.io.Pipe to connect the two active data sources
(doc.storeToUrl and XParameter.setBinaryStream).

Using dbase I succeeded in writing othe train to ut a doc this way, for
mysql or hsql the office hangs. See some code below, maybe the
limit-argument is the problem, which I set to 65536 as a limit and the
document was anytime smaller than that on storage (~30kB).

<code>
        ...
        sql = "INSERT INTO ""pieces"" (""ID"", ""piece"") VALUES (?, ?)"
        oPStatement = aConnection.prepareStatement( sql )
        oPStatement.setInt(1, aID)

        dim Args(0) as new com.sun.star.beans.PropertyValue

        oPipe = CreateUNOService("com.sun.star.io.Pipe")
        Args(0).Name = "OutputStream"
        Args(0).Value = oPipe ' s.u.

        ' order IS IMPORTANT !!! for dbase ...
        tmpDoc.storeToUrl("private:stream", Args())

        ' never-come-back-call ...
        oPStatement.setBinaryStream(2, oPipe, 65536)

        oPStatement.executeUpdate()

</code>

Marc



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to