Re: [Info-Ingres] Ingres 9.2 to 10.1 Migration
Paul White
Hi there Jay
There’s just one S in Ingres J
I can report just one problem migrating to 10.1
This incorrect statement ran ok in 9.x but produced error in 10.x
select distinct (varchar(effective_date)), cust_code
from customer_pricelist where cust_code = 'C00029'
order by effective_date desc
E_US0888 Sort column or expression not found in select list of distinct or grouped query.
The fix was
select distinct (varchar(effective_date)), cust_code
from customer_pricelist where cust_code = 'C00029'
order by varchar(effective_date) desc
You’ll get good response from Ingres forums. eg
https://groups.google.com/forum/#!forum/comp.databases.ingres
mailto:info-...@lists.planetingres.org
http://community.actian.com/forum/ingres-forums/
Paul White
&
Shift Seven Solutions
www.shift7solutions.com.au
From: openroa...@googlegroups.com
[mailto:openroa...@googlegroups.com] On Behalf Of Jayakumar Soyi
Sent: Friday, 8 August 2014 7:51 PM
To: openroa...@googlegroups.com
Subject: [openroad-users] Ingress 9.2 to 10.1 Migration
Hi All
Hope things are going good!!!
We are in the process of understanding the steps involved in Ingress 9.2 to Ingress 10.1 migration and need your guidance.
Source System: Ingress 9.2 in AIX
Destination System: Ingress 10.1 in Linux
Programming Language used: Ingress C
We are following the guidelines outlined in the link docs.actian.com
(following all the sub steps under the heading Creating a New Ingres Development Environment)
Questions related to Database migration:
1) other than the above link any other references need to be followed?
2) other helpful details?
Questions related to application migration/ Ingress C:
1) any code change will be required due to this migration? (eg: ifdef Unix - does this needs to be changed to ifdef - Linux?)
2) tutorial references for Ingress C?
Your guidance will be much helpful to us...
Thanks in advance,
Regards
Jay.
--
You received this message because you are subscribed to the Google Groups
"OpenROAD Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to openroad-user...@googlegroups.com.
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/CABb2waXMLeqsCenJPfkhZ01BhGfUX5gfZRRHEh7RsBZBnotS0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Sørensen.Henrik Georg HGO
We did the migration 1 year ago from Ingres 9.2.3 to 10.1.0, and as remember only some issues,
that should be solved by the present patches, except may be this one, related to the Database.
If using portioned tables there was an issue, so before migrating the database we’ve did a un-partitioning of these
Tables, migrated and did a re-partioning of the tables.
(No problem if you have scripts for the structure, and sorry we didn’t report it to support at that time).
In our case (and my knowledge of past migrations of Ingres versions) we also removed all of our own DB-rules,
DB-Procedures and Views, as well as Grants. (Jobs and Scripts as well to reload them).
This mainly as it often seems faster to do this, than let the Migration do this, and less chances of failures anyway.
But if you’re moving platform with unload/reloading of database this shouldn’t be a big issue anyway.
During the upgrade of Ingres versions we only did the Ingres internal migration for iidbdb and imadb, and waited with
Our own database until after the installations we’re patch up to the latest at that time.
At the moment only one open Issue on Ingres 10s (10.1 Linux 64bit), so don’t use a where criteria with 1 = 0
On a update or select as you properly would affect all rows instead of none (see previously mail to newsgroup still not solved!).
For your programs remember that Ingres 10 and upwards now support longer table and fieldnames, so if your
Programs support names for DB-objects in variables remember to raise the typical length from 32 to 64/256,
And so.
Migrations between Unix-versions could as well give some differences in C-code, Shell-scripts but that is not directly
Releated to Ingres, and would also depend on coding styles (only Ingres abf-issue was about removing ; on lines
With #include <inc/mydefs.h>; witch is more cpp-related than Ingres).
Had a lot of different issues during past migration a couple of years ago from TRU64 (axp.osf) to Linux,
about old-style C-code, Environment/permissions in Shell-scripts, Different flags and so on.
Kind regards
Henrik Georg Sørensen, Ingres DBA
Vi gør opmærksom på, at denne e-mail kan indeholde fortrolig information. Hvis du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen ved at bruge svarfunktionen. Samtidig beder vi dig slette e-mailen i dit system uden at videresende eller kopiere den. Selvom e-mailen og ethvert vedhæftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan påvirke computeren eller it-systemet, hvori den modtages og læses, åbnes den på modtagerens eget ansvar. Vi påtager os ikke noget ansvar for tab og skade, som er opstået i forbindelse med at modtage og bruge e-mailen.
Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or it-system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.
nikosv
Roy Hann
> are there any steps that should be taken for switching application code
> from using ANSI isolation to MVCC?
least) REPEATABLE READ so MVCC doesn't contradict ANSI isolation.
Unless you are actually relying on seeing the anomalies that the more
relaxed isolation levels allow then you should be OK. I can't think of a
case where I have ever *wanted* anomalies. But then again I never
write code that relies on dirty reads.
It may be that you will have to explicitly protect some transactions by
setting the isolation level to SERIALIZABLE instead of counting on a
blocking read-lock to make transactions take turns.
You use the SET TRANSACTION/SESSION ISOLATION statements in the same way
with MVCC as with pessimistic locking it's just that you will tend to
get better isolation and consistency than you ask for.
Using MVCC you can still get serialization failures but they may happen
in different places than under pessimistic locking. You should always
be ready to detect and handle serialization failures though, even
without MVCC (e.g. deadlocks).
All this is a round about way of saying it's probably easy to change
the code as required but it's not easy to know where you have to make
changes.
You need to know what your application does, in detail. How many places
you have to make a change to implement MVCC depends on the whether it
was written with isolation levels in mind or whether it
implicitly exploited knowledge of how pessimistic locking works. I think
most older Ingres application code assumes pessimistic locking simply
because a lot of it was written before ANSI isolation levels were
defined.
Roy
Ingres Forums
The big surprise for most people is that COMMIT can actually fail with
MVCC. There are a lot of applications out there that don't check the
error code from commit.
--
daryl...@ingres.com
------------------------------------------------------------------------
daryl...@ingres.com's Profile: http://community.actian.com/forum/member.php?userid=736
View this thread: http://community.actian.com/forum/showthread.php?t=16184