On Wed, 2013-03-13 at 22:29 +0100, Christian Grün wrote:
> Hi Cerstin,
> [...]
> You could try to export your data and create a new
> database without updatable index structures; this could also speed up
> your updates. Maybe it even allows you to update all nodes in a single
> run.
> > I alread
Hi Christian,
it works like a charm. Neither of the reported bugs could be reproduced with
the latest build (no matter what I've tried ;o)).
So *many* thanks for your prompt response and bugfix. This is why I love
open source projects in general und especially this project: there are
people who r
Bodo,
thanks for your in-depth bug report, which allowed me to track down
and fix the bug. Could you check out the latest stable snapshot [1]
and give us some feedback if the problem is resolved?
Best,
Christian
[1] http://files.basex.org/releases/latest/
___
On Wed, Mar
Hi Nesh,
as Johannes indicated, it could help to explicitly specify all child
steps to the PmtInf node.
Christian
___
On Wed, Mar 13, 2013 at 7:38 PM, Johannes.Lichtenberger
wrote:
> On 03/13/2013 05:04 PM, EV Narasimham wrote:
>>
>> Hi,
>> I'm currently processing
Hi Cerstin,
> However, my real data has about 140 000 of such entries and about 30 000 of
> such secondqueries, it's all in one database. Which is probably too big.
true; it may well be that the total amount of update operations is too
large to be processed in a single step. I would advise to t
Hi Christian,
I've tried to set GLOBALLOCK to TRUE today and this prevents the error.
a) I performed some more tests and found some more other errors (without
global locking, see attached log). Anyhow, I suspect an encoding issue for
specific input data so included the documents I have saved in
On 03/13/2013 05:04 PM, EV Narasimham wrote:
Hi,
I'm currently processing a 3GB xml file. Below is the Query that is
being executed and the corresponding output
count(db:open("ASEPXML",
"A_SEPXML")/descendant::*:PmtInf[15]/*:CdtTrfTxInf/*:CdtrAgt/*:FinInstnId/*:BIC/text())
Output: 10
Hi Christian,
Am 12.03.2013 um 19:33 schrieb Christian Grün :
> the following query may help:
>
> for $entry in $doc//entry
> let $next := $entry/following-sibling::entry[1]
> let $sc := $entry/following-sibling::secondquery
>[empty($next) or . << $next]
> return (
>insert nodes $sc
Christian,
Thanks, but I was hoping I could lure you (or someone else) into
suggesting what the syntax for a window clause might look like here!
:-) Since they are something I haven't mastered yet.
(Any takers?)
Cheers, Wendell
On Wed, Mar 13, 2013 at 10:25 AM, Christian Grün
wrote:
> Hi Wend
Hi,
I'm currently processing a 3GB xml file. Below is the Query that is
being executed and the corresponding output
count(db:open("ASEPXML",
"A_SEPXML")/descendant::*:PmtInf[15]/*:CdtTrfTxInf/*:CdtrAgt/*:FinInstnId/*:BIC/text())
Output: 10
The total time taken to evaluate the q
Hi Wendell,
good point. I agree that there are various ways to answer Cerstin’s
question. Window clauses should be a good fit here, and should most
probably provide better performance than requesting the following and
preceding axes of a node.
Christian
___
On Wed, Mar 13
Christian,
Alternatively, would this be a place one could use a 3.0 window clause?
This raises a related question. I have seen a big boost on performance
when using 'group by' instead of the classic distinct-values-based
grouping. I suppose this is not surprising. Cerstin's question,
similarly, i
12 matches
Mail list logo
