This is a 'fifo' type of problem and should have nothing
to do with disk space.

I wonder if this has something to do with the long file name.
Can you try renaming the database file to something shorter
to see if that helps out at all??

Other than that thought my next one is that the database
itself cannot be started. Let us know if the last suggestion
helps or not ...


"Geoff Elliott" wrote in message news:4b449ba1.4f44.1681692777 (AT) sybase (DOT) com...

On second thought, this is the real context involved here

Unloading "ps"."PS_SURGERY" (11993 rows)
***** SQL error: Statement interrupted by user
***** SQL error: Cannot access file '\\.\pipe\1360-ASANP_table\extrbld\1' --
Invalid argument


You may want to try your V9.0.x software to validate
that last table and even if that passes do a full validation
of the whole database to see if that reveals anything.



"Nick Elson [Sybase iAnywhere]" <@nick@dot@elson@at@sybase@dot@com@> wrote
in message news:4b464eff$1 (AT) forums-1-dub (DOT) ..

Thanks for the response Nick.

I have run DBVALID (v9) on both the PS_SURGERY table and the
whole database. No errors reported.

So I tried renaming the db file to a shorter name (temp.db)
and re-run the DBUNLOAD command, still get the same error.

I guess I'll have to resort to trying DBULOAD -an or do the
unload - reload stages manually unless there any other
thoughts on what might be happening here.

I have tried running the DBUNLOAD command below using the
Sybase v9 installation files and it seems to work fine. This
may be a v11 specific issue?

Geoff Elliott wrote:

It may be after all.

If you are running 2 or more dbunloads in parallel (say from a script that
does not use `start /wait dbunload ....`) then this bug fix may be important

SA Bug Fix ( QTS 523709 ) - Concurrent internal dbunload crash engine
Versions affected: all
Modules affected: engine, dbtools.dll
Fixed: 11.0.1#2186 , 11.0#1594 , 10.0.1#3868
Customer Description:
The engine may crash if multiple concurrent dbunload executions with
internal
rebuild (-an, -ar, -ac) are executed. This has been fixed.

and that could lead to the broken pipe error.

There could be others as well, so I would patch up to a more
recent EBF and try it again with that. [o\w show your exact
version and build pls]


"Geoff Elliott" wrote in message news:4b476c4f.2673.1681692777 (AT) sybase (DOT) com...

Ok I've tried again with latest EBF (windows x86
11.0.1.2355), still get the same issue. Alos tried just
doing an unload to a folder (-d <output folder) (no auto
load to new DB). This works fine.

I'm going to resort to raising a support call. But any
further help / thoughts would be approeciated.

We are going to update our estate to v11 (1700+ systems and
we are looking to develop a reliable upgrade script, the -ar
option would have made the script a lot simpler.

So a single copy of dbunload -ar with nothing else running
shows this problem?

That is unfortunate since dbunload -ar is the recommended
approach for the upgrade. [I assume with a 1700+ machine
inheritance you are running with dbremote or dbmlsync
so the use of -ar would be paramount here ... otherwise -an
could suffice.]

If it always fails on the same table, I would see if the rebuild
works just using the V9 software. There is a chance there is
a broken table or other database datastructure involved
here. While a full validation should detect corruption, the
rebuild may exercise the database in a different way.

All in all it sounds (to me) like **the server reading the V9
database** is going off the line; ie. crashing or doing
something almost as bad. The V9 rebuild should expose
any V9-specific behaviour. I expect to see one of two
outcomes from testing with a V9 rebuild (w dbunload -ar):

- It will work. After which then your V10
rebuild may just start to work.
- It will fail and we need to refocus on the problem
identified there, at that software version.

but there is always a 3rd option of a bug.

This "server reading the V9 database" is the main difference
between the way dbunload used to work and the way it
needs to work with V10+. The error you are seeing is
directly related to this difference and we would like to look
into that deeper. Especially so if this is not tied to
something broken inside of the source database.

The technical support route is advisable for since it is not
at all clear why it would break at that point and may
require an engineer to drill into this for you.

To make that process go smoother it would be best to
have a copy of your database that shows the problem.
While I suspect we are talking medical data here any
database with dummied up data that shows this problem
would be sufficient.

"Geoff Elliott" wrote in message news:4b4b297e.2127.1681692777 (AT) sybase (DOT) com...

I intend raisng this as a support case as soon as possible,
but in the mean time I have an update.

I ran dbunload -ar using Sybase v9, (effectively upgrading a
v9 database to v9) then ran the same command on the new v9
database using Sybase v11 version of dbunload. This seemed
to succesfully upgraded the database to v11. I don't know if
that helps understand what is happening. This will be a
problem for our live upgrade of 1700 stores of course.

I can supply an "anonymised" version of the database that
should show the issue if needed, I suspect I will need to
supply this when I raise the support case. The database is
quite large ~1 Gb

By the way there seems to be a large ".olg" file in the
database folder now. What is this file?

Nick Elson wrote:

Your .olg file is related to the completed dbunload -ar run. It
is just the old V9 transaction log renamed to help maintain the
ability to replicate and/or synchronize with the new database.
It is still a V9 format file still, but it is kept around for the next
few scans (with the delete_old_logs option enabled that is).

The fact that the V9 dbunload run corrects this problem, lends
credence to the theory you have some dbupgrade historical
artifact or an older file format that is exposing this behaviour.
That or an odd broken database issue that is, otherwise,
undectectible.

I don't yet think file size is an issue but we will see more once
you get that database to a support person to work on.

"Geoff Elliott" wrote in message news:4b549a85.fb3.1681692777 (AT) sybase (DOT) com...