Are you saying that due to the fact my database is fine in 6.5.1 but not in 6.6.3-SNAPSHOT implies my database is corrupt?
Do databases need to be 'migrated' every time you release a version (minor or major?)? If so, is there a migration utility?
Can you tell me what details you need? I won't be able to send you the XMLs forming this database. I can tell you, however, all I did was run a query which retrieved one element (having several descendent elements) from a sub-collection. The JAX-RX query was like: http://localhost:8984/basex/jax-rx/?run=getData.xq&var=$databaseName=MyD...
The XMLs were loaded via JAX-RX POST to http://localhost:8984/basex/jax-rx/MyDB/SubPath/SubSubPath/dataFileN where dataFileN is the unique name of the data-file being loaded (dataFileOne, dataFileTwo etc.). The database was created using JAX-RX command invocation (param command=CREATE+DATABASE+MyDB)
On Mon, May 23, 2011 at 11:51 AM, Christian Grün christian.gruen@gmail.com wrote:
It might be that your database is corrupt due to an old version of BaseX anyway. To give you more help, we'll need more details. Christian ___________________________
On Mon, May 23, 2011 at 12:00 PM, software developer computer.software.developer@gmail.com wrote:
Hi,
All I did was upgrade from 6.5.1 to 6.6.3-SNAPSHOT which I took from BaseX file-server today (a couple of hours ago) and I get: Not expected (Data Access out of bounds [pre:2050100, indexSize:8028, access:8028 > 8027]
This is quite similar to the issue I faced when I raised the original query regarding XQUF (this thread).
Immediately downgraded to 6.5.1 and the issue got fixed (I did not update the data at all).
Thanks.
On Wed, May 11, 2011 at 11:33 AM, Lukas Kircher lukaskircher1@googlemail.com wrote:
Hi,
thanks for your report. Just for clearance and for the benefit of other readers:
[...] All I can remember from yesterday is that first I was trying some incorrect replace statements (target of replace was a set of nodes instead of just one node) before using delete/insert statements ('cos I needed to replace a set of nodes).
You could use an iterative approach, i.e.
for $i in //node return replace node $n with <newnode/>
This serves as a general solution for similar issues, as an insert or rename statement only allows single target nodes as well.
If it helps, when I attempted a query in the UI yesterday (instead of JAX-RX), the database consistently threw some exception and suggested filing a bug report (I did not, unfortunately, store the details and the exception, so do not have access to the same right now).
Interesting ... my first guess would be that there was some kind of concurrent access between the BaseX server and the GUI version. Make sure you don't use them on the same database at the same time as this could lead to concurrent file access on disk. Although possible, it is not intended. We will try to state this in a clearer manner on our website/documentation.
My comments about insert were incorrect anyway, apologies for the same - I was mistakenly inserting into the parent element of the actual intended location (but was later checking the existence in the actual intended location)
No worries.
If it happens again, will be more meticulous and will store the various steps/logs. I was using BaseX 6.5.1, will upgrade to 6.6.2 now.
Good to hear. There are a lot of changes between different revisions and we're constantly improving the code base. So running the most recent version is highly encouraged.
Feel free to ask for more, regards, Lukas
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk