So I've never had the pleasure of moving Unidata from one OS to another,
but now do. We'll be moving from unidata 7.1.8 on Solaris 9 to Unidata
7.2.x on RedHat Enterprise.
At this point I'm just playing but would like advice on preferred ways
to migrate tables from Solaris to RedHat. I tried
[snip]
high byte order vs low byte order.
[snip]
It has been a really long time and my memory isn't what it was but, you may
want to look at putting something like zip onto the machines and compiling
(if your version doesn't have it already). Then just zip up your data and
move it to the new
[ad]
U2logic is pleased to announce that we have a native interface for PHP.
Our proven middleware U2WebLink(tm) using UniObjects for Java can provide
you with
the security, logging, and connection management you have been looking for
our PHP
applications.
U2WebLink(tm) gives you access to TCL
Jeff:
I don't believe UniData has any save/restore capability, so that
method won't work. :-(
Because of this, I think there is pretty good documentation in
Administering UniData on Windows Platforms. You can also look at the
UniAdmin manual, as these functions are discussed there.
There is an outstanding issue with convidx with a heavily overflowed index file.
Fortunately you can delete the index before migrating and re-create and rebuild
in on the new box.
I don't know of any problems with convdata or convcode.
Are you sure the technique you used to move your files kept
Are you sure the technique you used to move your files kept them intact?
tarred them on Solaris
Used scp to transfer to new host
untarred on linux
Of course the database on the source system would need to be paused or
down - to be sure the files are in good state before moving them.
This
I haven't been following this thread but it occurs to me to point out that
Linux machine is probably running Intel chips with a different byte order to
that used on the Solaris machine. If that point's already been made then
please ignore this observation.
On Thu, 19 Nov 2009, Ray Wurlod wrote:
I haven't been following this thread but it occurs to me to point out that
Linux machine is probably running Intel chips with a different byte order to
that used on the Solaris machine. If that point's already been made then
please ignore this
I thought I would dig this back up and tell what we did to fix this problem, in
case someone searches for our fix. This was under the advisement of Rocket.
I used fixtool instead of uvfixfile. It corrected the corruption problem.
I created a new 64 bit file that could hold the large amount of
I have moved a couple of installs of UniVerse from AIX and Windows to RH
Linux. I have found that the easiest was to do this is to use UniAdmin to
do an account save on the old system and then use UniAdmin on the new
system to restore the account. I usually do the backup to a file and ftp
the
I do not know what is causing the peformance problem with Unidata and
indexed fields, using large key. In the case of this particular file, there
are translated fields that have to be built separately from the other 'D'
type fields. The field in questions, that I was selecting on, was a date
Have you defined NO.NULLS on the DATE field index?
The condition less than equal to will be catering for or Null as being
less than 0, whereas the SELECTINDEX in the program version will be using
Date values (hence missing the less than equals part.
$0.02, HTH.
Cheers,
Brian.
-Original
12 matches
Mail list logo
