Art,
You say "If the RSS or HDR secondary is writable, the writes are still
happening on the primary" and then later "If the WAN goes down you could
continue to process transactions locally". I'm confused by this - if all
writes are happening on the primary, then how could I continue to process
transaction locally?
I guess my big question here is if I should be using an RSS at Site1 or an HDR
secondary. I was under the impression that if I was using an HDR secondary and
the WAN link went down, then the HDR primary at HQ would not be able to
process transactions (insert/update/delete) because it could not sync with the
offline HDR secondary at Site1 - am I wrong on this?
-Justin
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Thursday, May 23, 2013 10:53 AM
To: ids@iiug.org
Subject: Re: database replication setup help [30329]
OK, here are some points:
- If the RSS or HDR secondary is writable, the writes are still
happening on the primary (passed through by the secondary) and then
propagate to the secondaries including the secondary the originated the
write. There is no danger of the secondary getting out-of-sync with the
primary and having local transactions that the primary doesn't know about.
If the WAN goes down, you could still use the local RSS secondary at Site1
as a read-only query server, but would have to get the WAN back up in order
to process updates locally again.
- If you make the secondary read-only, then you apps will have to be
aware of that and either update the primary using distributed queries (ie
access the table's using the primary's servername: insert into
mydatabase@primary:mytable ...) or they could keep two connections open
(assuming the host language supports multiple connections (ESQL/C, C++, all
4GL variants, and Java do) one locally on the secondary for reading and one
remoted directly to the primary for updating. The writable option is
actually preferrable.
- You could use ER. If the WAN goes down you could continue to process
transactions locally, but when the LAN comes back up then conflict
resolution rules would have to resolve any problems caused by rows updated
on multiple servers.
- HDR and RSS secondaries will remain in sync for schema changes because
all logical log records (which include all DDL commands) are propagated to
the secondaries and applied there replicating changes happening on the
primary. Only index builds are slightly different. They can be configured
such that the secondary just gets notice of a new index and has to build it
locally or such that the actual log records generated by the index build
are sent over to the secondary replicating the index page-by-page. Your
choice. Indexes built the first way, the default, will remain locked on
the primary until the secondaries complete their build (unless the
connection is down).
- Flexible Grid is just a new internal communication protocol that lets
you issue commands that are processed across all servers on a named grid.
Those servers can be ER participants or independent servers. Prior to
v12.10 this could only be used for ER commands and DDL. In 12.10 you can
also distribute queries across the grid and return data from multiple
servers with a single SELECT.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, May 23, 2013 at 1:31 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:
> Hi.
>
> For the last several years, we've been running an Informix database for our
> accounting and production systems. We have two primary locations, which for
> the purpose of this email I'll call HQ and Site1. Site1 is connected to HQ
> over a WAN link (T1, etc), but we are investigating possible options to
> change
> this to use Informix's replication (mainly to speed up access). HQ and
> Site1
> both work on the same data sets, so in the event the line goes down, we
> would
> prefer Site1 be read-only to avoid any data conflicts. Additionally, we
> like
> to add redundancy in the HQ location to prevent down-time in the event of
> server hardware failure, etc.
>
> After some research and reading, here's what we've come up with:
>
> HQ location:
> 1 HDR primary server
> 1 HDR secondary server
>
> Site1:
> 1 RSS server (readonly)
>
> Does this sound reasonable?
> When a program is run from Site1, and an update/insert/delete statement is
> run, how do we set it up so that the statement gets sent up to the HQ
> primary
> transparently?
> I read that schema change propagation only happens in Flexible Grid and
> not in
> ER, so when a schema change is made on the HDR primary, does it
> automatically
> propagate down to the secondary and RSS servers? I'm a little confused
> about
> the difference between Flexible Grid and ER and how they work together.
>
> Thanks In Advance,
> -Justin
>
>
>
>
>
>
>
--089e0160a3b8e43e8c04dd6658f1
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30334]
*******************************************************************************
RE: database replication setup help
↧
↧
Re: database replication setup help
First, you are misreading and combining two of my points. As relates to
RSS secondaries (same applies to HDR secondary BTW), I said: "If the WAN
goes down, you could still use the local RSS secondary at Site1 as a
read-only query server, but would have to get the WAN back up in order to
process updates (read that as transactions) locally again." I only said
that you could "continue to process transactions locally" with reference to
ER nodes where you might run into the conflict issues that you alluded to
in your post.
Now, I mentioned this when Larry said you could have two HDR secondaries,
but let me repeat it:
YOU CANNOT HAVE MORE THAN ONE HDR SECONDARY CONFIGURED AT THE SAME TIME!
After the one, single, lone, solitary (did I emphasize that enough?) HDR
secondary all other secondary servers have to be either SDS secondaries
attached to a primary server's disk drives or RSS secondaries which is what
you want to configure at Site1.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, May 23, 2013 at 2:43 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:
> Art,
>
> You say "If the RSS or HDR secondary is writable, the writes are still
> happening on the primary" and then later "If the WAN goes down you could
> continue to process transactions locally". I'm confused by this - if all
> writes are happening on the primary, then how could I continue to process
> transaction locally?
>
> I guess my big question here is if I should be using an RSS at Site1 or an
> HDR
> secondary. I was under the impression that if I was using an HDR secondary
> and
> the WAN link went down, then the HDR primary at HQ would not be able to
> process transactions (insert/update/delete) because it could not sync with
> the
> offline HDR secondary at Site1 - am I wrong on this?
>
> -Justin
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, May 23, 2013 10:53 AM
> To: ids@iiug.org
> Subject: Re: database replication setup help [30329]
>
> OK, here are some points:
>
> - If the RSS or HDR secondary is writable, the writes are still
>
> happening on the primary (passed through by the secondary) and then
>
> propagate to the secondaries including the secondary the originated the
>
> write. There is no danger of the secondary getting out-of-sync with the
>
> primary and having local transactions that the primary doesn't know about.
>
> If the WAN goes down, you could still use the local RSS secondary at Site1
>
> as a read-only query server, but would have to get the WAN back up in order
>
> to process updates locally again.
>
> - If you make the secondary read-only, then you apps will have to be
>
> aware of that and either update the primary using distributed queries (ie
>
> access the table's using the primary's servername: insert into
>
> mydatabase@primary:mytable ...) or they could keep two connections open
>
> (assuming the host language supports multiple connections (ESQL/C, C++, all
>
> 4GL variants, and Java do) one locally on the secondary for reading and one
>
> remoted directly to the primary for updating. The writable option is
>
> actually preferrable.
>
> - You could use ER. If the WAN goes down you could continue to process
>
> transactions locally, but when the LAN comes back up then conflict
>
> resolution rules would have to resolve any problems caused by rows updated
>
> on multiple servers.
>
> - HDR and RSS secondaries will remain in sync for schema changes because
>
> all logical log records (which include all DDL commands) are propagated to
>
> the secondaries and applied there replicating changes happening on the
>
> primary. Only index builds are slightly different. They can be configured
>
> such that the secondary just gets notice of a new index and has to build it
>
> locally or such that the actual log records generated by the index build
>
> are sent over to the secondary replicating the index page-by-page. Your
>
> choice. Indexes built the first way, the default, will remain locked on
>
> the primary until the secondaries complete their build (unless the
>
> connection is down).
>
> - Flexible Grid is just a new internal communication protocol that lets
>
> you issue commands that are processed across all servers on a named grid.
>
> Those servers can be ER participants or independent servers. Prior to
>
> v12.10 this could only be used for ER commands and DDL. In 12.10 you can
>
> also distribute queries across the grid and return data from multiple
>
> servers with a single SELECT.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those of
> other individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Thu, May 23, 2013 at 1:31 PM, Justin Killen <
> jkillen@allamericanasphalt.com> wrote:
>
> > Hi.
> >
> > For the last several years, we've been running an Informix database for
> our
> > accounting and production systems. We have two primary locations, which
> for
> > the purpose of this email I'll call HQ and Site1. Site1 is connected to
> HQ
> > over a WAN link (T1, etc), but we are investigating possible options to
> > change
> > this to use Informix's replication (mainly to speed up access). HQ and
> > Site1
> > both work on the same data sets, so in the event the line goes down, we
> > would
> > prefer Site1 be read-only to avoid any data conflicts. Additionally, we
> > like
> > to add redundancy in the HQ location to prevent down-time in the event of
> > server hardware failure, etc.
> >
> > After some research and reading, here's what we've come up with:
> >
> > HQ location:
> > 1 HDR primary server
> > 1 HDR secondary server
> >
> > Site1:
> > 1 RSS server (readonly)
> >
> > Does this sound reasonable?
> > When a program is run from Site1, and an update/insert/delete statement
> is
> > run, how do we set it up so that the statement gets sent up to the HQ
> > primary
> > transparently?
> > I read that schema change propagation only happens in Flexible Grid and
> > not in
> > ER, so when a schema change is made on the HDR primary, does it
> > automatically
> > propagate down to the secondary and RSS servers? I'm a little confused
> > about
> > the difference between Flexible Grid and ER and how they work together.
> >
> > Thanks In Advance,
> > -Justin
> >
> >
> >
> >
>
>
>
> >
> >
> >
>
> --089e0160a3b8e43e8c04dd6658f1
>
>
>
>
>
>
>
>
>
>
>
>
--047d7b3a82365e732f04dd67377f
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30335]
*******************************************************************************
↧
Re: Using dbaccess remotely on Windows Server
ODBC connections don't require setnet32 to be configured but native
Informix (SQLI) connections do, so you have to go into setnet32 and define
the server's host address, the servername, port, and protocol (onsoctcp or
drsoctcp) as appropriate to the server. You have already put these values
into the DSN setup for ODBC, but you still have to do it again for SQLI.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, May 23, 2013 at 1:46 PM, MARK HEPTINSTALL <djphatic@gmail.com>wrote:
> Is there anything in particular in setnet32 we would need to do on the UNIX
> server and/or the Windows server? We do already have ODBC connections
> setup on
> the Windows server.
>
> There is a dbaccess executable in the installed folder of the CSDK on the
> Windows Server though when it is run the following error is displayed in
> the
> DOS prompt.
>
> ERROR: Could not initialize the security subsystem. Please ensure that this
> account has the necessary privileges and ensure INFORMIXSERVER value
> exists in
> the registry and environment.
>
> The supplier does not want us executing ad-hoc queries against the
> database.
> Using this method we can bring a copy of the data into a different
> environment
> which should have minimal impact on the server/database performance. We can
> live with a lag of one day in data for the majority of reports.
>
> I'm not sure whether our I.T. department know what version of Informix we
> will
> be using, I believe this has been left to the supplier of the application.
>
>
>
>
>
>
>
--001a11c37a842eded004dd674da4
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30336]
*******************************************************************************
↧
RE: database replication setup help
If you run HDR to "Site1" and your WAN drops, your HDR primary should just
continue to run. What it will do is hold the logs until the WAN is back and
the secondary asks for them. If the logs turn over while the secondary is
down, you have to either replay logs from tape on the secondary or do a
physical restore of the database on the secondary to restart replication.
--EEM
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Justin
Killen
Sent: Thursday, May 23, 2013 1:43 PM
To: ids@iiug.org
Subject: RE: database replication setup help [30334]
Art,
You say "If the RSS or HDR secondary is writable, the writes are still
happening on the primary" and then later "If the WAN goes down you could
continue to process transactions locally". I'm confused by this - if all
writes are happening on the primary, then how could I continue to process
transaction locally?
I guess my big question here is if I should be using an RSS at Site1 or an HDR
secondary. I was under the impression that if I was using an HDR secondary and
the WAN link went down, then the HDR primary at HQ would not be able to
process transactions (insert/update/delete) because it could not sync with the
offline HDR secondary at Site1 - am I wrong on this?
-Justin
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Thursday, May 23, 2013 10:53 AM
To: ids@iiug.org
Subject: Re: database replication setup help [30329]
OK, here are some points:
- If the RSS or HDR secondary is writable, the writes are still
happening on the primary (passed through by the secondary) and then
propagate to the secondaries including the secondary the originated the
write. There is no danger of the secondary getting out-of-sync with the
primary and having local transactions that the primary doesn't know about.
If the WAN goes down, you could still use the local RSS secondary at Site1
as a read-only query server, but would have to get the WAN back up in order
to process updates locally again.
- If you make the secondary read-only, then you apps will have to be
aware of that and either update the primary using distributed queries (ie
access the table's using the primary's servername: insert into
mydatabase@primary:mytable ...) or they could keep two connections open
(assuming the host language supports multiple connections (ESQL/C, C++, all
4GL variants, and Java do) one locally on the secondary for reading and one
remoted directly to the primary for updating. The writable option is
actually preferrable.
- You could use ER. If the WAN goes down you could continue to process
transactions locally, but when the LAN comes back up then conflict
resolution rules would have to resolve any problems caused by rows updated
on multiple servers.
- HDR and RSS secondaries will remain in sync for schema changes because
all logical log records (which include all DDL commands) are propagated to
the secondaries and applied there replicating changes happening on the
primary. Only index builds are slightly different. They can be configured
such that the secondary just gets notice of a new index and has to build it
locally or such that the actual log records generated by the index build
are sent over to the secondary replicating the index page-by-page. Your
choice. Indexes built the first way, the default, will remain locked on
the primary until the secondaries complete their build (unless the
connection is down).
- Flexible Grid is just a new internal communication protocol that lets
you issue commands that are processed across all servers on a named grid.
Those servers can be ER participants or independent servers. Prior to
v12.10 this could only be used for ER commands and DDL. In 12.10 you can
also distribute queries across the grid and return data from multiple
servers with a single SELECT.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, May 23, 2013 at 1:31 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:
> Hi.
>
> For the last several years, we've been running an Informix database
> for our accounting and production systems. We have two primary
> locations, which for the purpose of this email I'll call HQ and Site1.
> Site1 is connected to HQ over a WAN link (T1, etc), but we are
> investigating possible options to change this to use Informix's
> replication (mainly to speed up access). HQ and
> Site1
> both work on the same data sets, so in the event the line goes down,
> we would prefer Site1 be read-only to avoid any data conflicts.
> Additionally, we like to add redundancy in the HQ location to prevent
> down-time in the event of server hardware failure, etc.
>
> After some research and reading, here's what we've come up with:
>
> HQ location:
> 1 HDR primary server
> 1 HDR secondary server
>
> Site1:
> 1 RSS server (readonly)
>
> Does this sound reasonable?
> When a program is run from Site1, and an update/insert/delete
> statement is run, how do we set it up so that the statement gets sent
> up to the HQ primary transparently?
> I read that schema change propagation only happens in Flexible Grid
> and not in ER, so when a schema change is made on the HDR primary,
> does it automatically propagate down to the secondary and RSS servers?
> I'm a little confused about the difference between Flexible Grid and
> ER and how they work together.
>
> Thanks In Advance,
> -Justin
>
>
>
>
>
>
>
--089e0160a3b8e43e8c04dd6658f1
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30337]
*******************************************************************************
↧
RE: database replication setup help
Art,
I'm sorry if I offended, that was not my intention. I see your contributions
to this community and I respect your advice and opinions. I am quite certain
that I am just simply misunderstanding some core concept (in my defense, IBM
has done a pretty good job of providing an abundance of acronyms and options
as to make everything complicated IMHO).
So then, when you say I can continue to process transactions, you mean that
the primary HDR at HQ continues to run, even in the event that the connection
to an HDR secondary/RSS is severed, and that any nodes connected to the now
disconnected HDR secondary/RSS will work for read requests but get an error on
write requests. The question here then is what's the difference between an HDR
secondary and an RSS? I thought the difference was that when applying a
transaction, the changes were guaranteed on a secondary because it happens at
the same time as the primary update, but for RSS it is not guaranteed because
the change is delayed?
-Justin
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Thursday, May 23, 2013 11:55 AM
To: ids@iiug.org
Subject: Re: database replication setup help [30335]
First, you are misreading and combining two of my points. As relates to
RSS secondaries (same applies to HDR secondary BTW), I said: "If the WAN
goes down, you could still use the local RSS secondary at Site1 as a
read-only query server, but would have to get the WAN back up in order to
process updates (read that as transactions) locally again." I only said
that you could "continue to process transactions locally" with reference to
ER nodes where you might run into the conflict issues that you alluded to
in your post.
Now, I mentioned this when Larry said you could have two HDR secondaries,
but let me repeat it:
YOU CANNOT HAVE MORE THAN ONE HDR SECONDARY CONFIGURED AT THE SAME TIME!
After the one, single, lone, solitary (did I emphasize that enough?) HDR
secondary all other secondary servers have to be either SDS secondaries
attached to a primary server's disk drives or RSS secondaries which is what
you want to configure at Site1.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, May 23, 2013 at 2:43 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:
> Art,
>
> You say "If the RSS or HDR secondary is writable, the writes are still
> happening on the primary" and then later "If the WAN goes down you could
> continue to process transactions locally". I'm confused by this - if all
> writes are happening on the primary, then how could I continue to process
> transaction locally?
>
> I guess my big question here is if I should be using an RSS at Site1 or an
> HDR
> secondary. I was under the impression that if I was using an HDR secondary
> and
> the WAN link went down, then the HDR primary at HQ would not be able to
> process transactions (insert/update/delete) because it could not sync with
> the
> offline HDR secondary at Site1 - am I wrong on this?
>
> -Justin
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, May 23, 2013 10:53 AM
> To: ids@iiug.org
> Subject: Re: database replication setup help [30329]
>
> OK, here are some points:
>
> - If the RSS or HDR secondary is writable, the writes are still
>
> happening on the primary (passed through by the secondary) and then
>
> propagate to the secondaries including the secondary the originated the
>
> write. There is no danger of the secondary getting out-of-sync with the
>
> primary and having local transactions that the primary doesn't know about.
>
> If the WAN goes down, you could still use the local RSS secondary at Site1
>
> as a read-only query server, but would have to get the WAN back up in order
>
> to process updates locally again.
>
> - If you make the secondary read-only, then you apps will have to be
>
> aware of that and either update the primary using distributed queries (ie
>
> access the table's using the primary's servername: insert into
>
> mydatabase@primary:mytable ...) or they could keep two connections open
>
> (assuming the host language supports multiple connections (ESQL/C, C++, all
>
> 4GL variants, and Java do) one locally on the secondary for reading and one
>
> remoted directly to the primary for updating. The writable option is
>
> actually preferrable.
>
> - You could use ER. If the WAN goes down you could continue to process
>
> transactions locally, but when the LAN comes back up then conflict
>
> resolution rules would have to resolve any problems caused by rows updated
>
> on multiple servers.
>
> - HDR and RSS secondaries will remain in sync for schema changes because
>
> all logical log records (which include all DDL commands) are propagated to
>
> the secondaries and applied there replicating changes happening on the
>
> primary. Only index builds are slightly different. They can be configured
>
> such that the secondary just gets notice of a new index and has to build it
>
> locally or such that the actual log records generated by the index build
>
> are sent over to the secondary replicating the index page-by-page. Your
>
> choice. Indexes built the first way, the default, will remain locked on
>
> the primary until the secondaries complete their build (unless the
>
> connection is down).
>
> - Flexible Grid is just a new internal communication protocol that lets
>
> you issue commands that are processed across all servers on a named grid.
>
> Those servers can be ER participants or independent servers. Prior to
>
> v12.10 this could only be used for ER commands and DDL. In 12.10 you can
>
> also distribute queries across the grid and return data from multiple
>
> servers with a single SELECT.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those of
> other individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Thu, May 23, 2013 at 1:31 PM, Justin Killen <
> jkillen@allamericanasphalt.com> wrote:
>
> > Hi.
> >
> > For the last several years, we've been running an Informix database for
> our
> > accounting and production systems. We have two primary locations, which
> for
> > the purpose of this email I'll call HQ and Site1. Site1 is connected to
> HQ
> > over a WAN link (T1, etc), but we are investigating possible options to
> > change
> > this to use Informix's replication (mainly to speed up access). HQ and
> > Site1
> > both work on the same data sets, so in the event the line goes down, we
> > would
> > prefer Site1 be read-only to avoid any data conflicts. Additionally, we
> > like
> > to add redundancy in the HQ location to prevent down-time in the event of
> > server hardware failure, etc.
> >
> > After some research and reading, here's what we've come up with:
> >
> > HQ location:
> > 1 HDR primary server
> > 1 HDR secondary server
> >
> > Site1:
> > 1 RSS server (readonly)
> >
> > Does this sound reasonable?
> > When a program is run from Site1, and an update/insert/delete statement
> is
> > run, how do we set it up so that the statement gets sent up to the HQ
> > primary
> > transparently?
> > I read that schema change propagation only happens in Flexible Grid and
> > not in
> > ER, so when a schema change is made on the HDR primary, does it
> > automatically
> > propagate down to the secondary and RSS servers? I'm a little confused
> > about
> > the difference between Flexible Grid and ER and how they work together.
> >
> > Thanks In Advance,
> > -Justin
> >
> >
> >
> >
>
>
>
> >
> >
> >
>
> --089e0160a3b8e43e8c04dd6658f1
>
>
>
>
>
>
>
>
>
>
>
>
--047d7b3a82365e732f04dd67377f
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30338]
*******************************************************************************
↧
↧
Gui interface
Does anyone have any suggestions of a good gui to use from a PC to
informix .. We have been using the old "sql editor' which came out I
think with SDK 2.4 .. Our developers are looking for something more
"modern", that is them talking not me....and of course free is better than
paid ...
IDS 11.50, 11.70
Aix 6.1, 7.1
Thanks a bunch ...
Peter Logan
Senior Database Administrator
Phone: 616/878-8309
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30339]
*******************************************************************************
↧
Re: database replication setup help
No offense taken, I guess I'm just in a cranky mood. Not your fault dude.
Let's take this offline. Will contact you directly.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, May 23, 2013 at 4:03 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:
> Art,
>
> I'm sorry if I offended, that was not my intention. I see your
> contributions
> to this community and I respect your advice and opinions. I am quite
> certain
> that I am just simply misunderstanding some core concept (in my defense,
> IBM
> has done a pretty good job of providing an abundance of acronyms and
> options
> as to make everything complicated IMHO).
>
> So then, when you say I can continue to process transactions, you mean that
> the primary HDR at HQ continues to run, even in the event that the
> connection
> to an HDR secondary/RSS is severed, and that any nodes connected to the now
> disconnected HDR secondary/RSS will work for read requests but get an
> error on
> write requests. The question here then is what's the difference between an
> HDR
> secondary and an RSS? I thought the difference was that when applying a
> transaction, the changes were guaranteed on a secondary because it happens
> at
> the same time as the primary update, but for RSS it is not guaranteed
> because
> the change is delayed?
>
> -Justin
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, May 23, 2013 11:55 AM
> To: ids@iiug.org
> Subject: Re: database replication setup help [30335]
>
> First, you are misreading and combining two of my points. As relates to
> RSS secondaries (same applies to HDR secondary BTW), I said: "If the WAN
> goes down, you could still use the local RSS secondary at Site1 as a
> read-only query server, but would have to get the WAN back up in order to
> process updates (read that as transactions) locally again." I only said
> that you could "continue to process transactions locally" with reference to
> ER nodes where you might run into the conflict issues that you alluded to
> in your post.
>
> Now, I mentioned this when Larry said you could have two HDR secondaries,
> but let me repeat it:
>
> YOU CANNOT HAVE MORE THAN ONE HDR SECONDARY CONFIGURED AT THE SAME TIME!
>
> After the one, single, lone, solitary (did I emphasize that enough?) HDR
> secondary all other secondary servers have to be either SDS secondaries
> attached to a primary server's disk drives or RSS secondaries which is what
> you want to configure at Site1.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those of
> other individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Thu, May 23, 2013 at 2:43 PM, Justin Killen <
> jkillen@allamericanasphalt.com> wrote:
>
> > Art,
> >
> > You say "If the RSS or HDR secondary is writable, the writes are still
> > happening on the primary" and then later "If the WAN goes down you could
> > continue to process transactions locally". I'm confused by this - if all
> > writes are happening on the primary, then how could I continue to process
> > transaction locally?
> >
> > I guess my big question here is if I should be using an RSS at Site1 or
> an
> > HDR
> > secondary. I was under the impression that if I was using an HDR
> secondary
> > and
> > the WAN link went down, then the HDR primary at HQ would not be able to
> > process transactions (insert/update/delete) because it could not sync
> with
> > the
> > offline HDR secondary at Site1 - am I wrong on this?
> >
> > -Justin
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art
> > Kagel
> > Sent: Thursday, May 23, 2013 10:53 AM
> > To: ids@iiug.org
> > Subject: Re: database replication setup help [30329]
> >
> > OK, here are some points:
> >
> > - If the RSS or HDR secondary is writable, the writes are still
> >
> > happening on the primary (passed through by the secondary) and then
> >
> > propagate to the secondaries including the secondary the originated the
> >
> > write. There is no danger of the secondary getting out-of-sync with the
> >
> > primary and having local transactions that the primary doesn't know
> about.
> >
> > If the WAN goes down, you could still use the local RSS secondary at
> Site1
> >
> > as a read-only query server, but would have to get the WAN back up in
> order
> >
> > to process updates locally again.
> >
> > - If you make the secondary read-only, then you apps will have to be
> >
> > aware of that and either update the primary using distributed queries (ie
> >
> > access the table's using the primary's servername: insert into
> >
> > mydatabase@primary:mytable ...) or they could keep two connections open
> >
> > (assuming the host language supports multiple connections (ESQL/C, C++,
> all
> >
> > 4GL variants, and Java do) one locally on the secondary for reading and
> one
> >
> > remoted directly to the primary for updating. The writable option is
> >
> > actually preferrable.
> >
> > - You could use ER. If the WAN goes down you could continue to process
> >
> > transactions locally, but when the LAN comes back up then conflict
> >
> > resolution rules would have to resolve any problems caused by rows
> updated
> >
> > on multiple servers.
> >
> > - HDR and RSS secondaries will remain in sync for schema changes because
> >
> > all logical log records (which include all DDL commands) are propagated
> to
> >
> > the secondaries and applied there replicating changes happening on the
> >
> > primary. Only index builds are slightly different. They can be configured
> >
> > such that the secondary just gets notice of a new index and has to build
> it
> >
> > locally or such that the actual log records generated by the index build
> >
> > are sent over to the secondary replicating the index page-by-page. Your
> >
> > choice. Indexes built the first way, the default, will remain locked on
> >
> > the primary until the secondaries complete their build (unless the
> >
> > connection is down).
> >
> > - Flexible Grid is just a new internal communication protocol that lets
> >
> > you issue commands that are processed across all servers on a named grid.
> >
> > Those servers can be ER participants or independent servers. Prior to
> >
> > v12.10 this could only be used for ER commands and DDL. In 12.10 you can
> >
> > also distribute queries across the grid and return data from multiple
> >
> > servers with a single SELECT.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other organization with which I am associated either explicitly,
> > implicitly, or by inference. Neither do those opinions reflect those of
> > other individuals affiliated with any entity with which I am affiliated
> nor
> > those of the entities themselves.
> >
> > On Thu, May 23, 2013 at 1:31 PM, Justin Killen <
> > jkillen@allamericanasphalt.com> wrote:
> >
> > > Hi.
> > >
> > > For the last several years, we've been running an Informix database for
> > our
> > > accounting and production systems. We have two primary locations, which
> > for
> > > the purpose of this email I'll call HQ and Site1. Site1 is connected to
> > HQ
> > > over a WAN link (T1, etc), but we are investigating possible options to
> > > change
> > > this to use Informix's replication (mainly to speed up access). HQ and
> > > Site1
> > > both work on the same data sets, so in the event the line goes down, we
> > > would
> > > prefer Site1 be read-only to avoid any data conflicts. Additionally, we
> > > like
> > > to add redundancy in the HQ location to prevent down-time in the event
> of
> > > server hardware failure, etc.
> > >
> > > After some research and reading, here's what we've come up with:
> > >
> > > HQ location:
> > > 1 HDR primary server
> > > 1 HDR secondary server
> > >
> > > Site1:
> > > 1 RSS server (readonly)
> > >
> > > Does this sound reasonable?
> > > When a program is run from Site1, and an update/insert/delete statement
> > is
> > > run, how do we set it up so that the statement gets sent up to the HQ
> > > primary
> > > transparently?
> > > I read that schema change propagation only happens in Flexible Grid and
> > > not in
> > > ER, so when a schema change is made on the HDR primary, does it
> > > automatically
> > > propagate down to the secondary and RSS servers? I'm a little confused
> > > about
> > > the difference between Flexible Grid and ER and how they work together.
> > >
> > > Thanks In Advance,
> > > -Justin
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
> > >
> > >
> > >
> >
> > --089e0160a3b8e43e8c04dd6658f1
> >
> >
> >
> >
>
>
>
> >
> >
> >
> >
> >
>
>
>
> >
> >
> >
>
> --047d7b3a82365e732f04dd67377f
>
>
>
>
>
>
>
>
>
>
>
>
--089e0160a3b8a1f06404dd6863c7
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30340]
*******************************************************************************
↧
Re: Gui interface
Check out SquirrelSQL or the SQL Editor in OAT.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, May 23, 2013 at 4:11 PM, Peter_Logan@spartanstores.com <
Peter_Logan@spartanstores.com> wrote:
> Does anyone have any suggestions of a good gui to use from a PC to
> informix .. We have been using the old "sql editor' which came out I
> think with SDK 2.4 .. Our developers are looking for something more
> "modern", that is them talking not me....and of course free is better than
> paid ...
>
> IDS 11.50, 11.70
> Aix 6.1, 7.1
>
> Thanks a bunch ...
>
> Peter Logan
> Senior Database Administrator
> Phone: 616/878-8309
>
>
>
>
>
>
>
--001a11c3657ad3121b04dd688d75
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30341]
*******************************************************************************
↧
Re: Gui interface
On 23/05/13 21:11, Peter_Logan@spartanstores.com wrote:
> Does anyone have any suggestions of a good gui to use from a PC to
> informix .. We have been using the old "sql editor' which came out I
> think with SDK 2.4 .. Our developers are looking for something more
> "modern", that is them talking not me....and of course free is better than
> paid ...
>
> IDS 11.50, 11.70
> Aix 6.1, 7.1
>
> Thanks a bunch ...
>
> Peter Logan
> Senior Database Administrator
> Phone: 616/878-8309
Have a look at SQSL (see sig) - GUI(is if you build with Aubit4gl, and it does
have a win32 port
--
Ciao,
Marco
______________________________________________________________________________
Marco Greco /UK /IBM Standard disclaimers apply!
Structured Query Scripting Language http://www.4glworks.com/sqsl.htm
4glworks http://www.4glworks.com
Informix on Linux http://www.4glworks.com/ifmxlinux.htm
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30342]
*******************************************************************************
↧
↧
RE: query bts_contains to obtain attribute value
Hola Tatiana.
Try this:
{ Table "informix".tab1 row
size = 56 number of columns = 1 index size = 0 }
create table "informix".tab1
( col2 text
) extent size 16 next size 16 lock mode
row;
revoke all on "informix".tab1
"public" as "informix";
<personal> <person
id='Jason.Ma'> <name> <family>Ma</family>
<given>Jessica</given> </name> </person> </personal>
SELECT extract(col2,
'/personal/person[@id="Jason.Ma"]/name/given') FROM tab1;
> To: ids@iiug.org
> From: jessytapoli@hotmail.com
> Subject: query bts_contains to obtain attribute value [30312]
> Date: Tue, 21 May 2013 12:52:56 -0400
>
> Hi everybody.
>
> I am looking the best way to retrieve an attribute value from a XML column
> stored in lvarchar field.
>
> I am using BTS datablade with the new parameter all_xmlattrs on index BTS
just
> like this:
>
> create index mibts_idx on mitab1 (col2 bts_lvarchar_ops) using bts
> (xmlpath_processing='yes', all_xmlattrs='yes') in sbspace;
>
> And using the function bts_index_fields to retrieve the paths were indexed.
> Obtaining:
>
> /airplane
> /airplane@callsign
> /boat/name
> /boat/name@reg
>
> If I am looking for the value of "callsign" attribute ... how it would be
the
> correct SELECT statement through the bts_contains function???
>
> I am using:
>
> SELECT COL2 FROM MITAB1 WHERE bts_contains(col2,'/airplane@callsign');
>
> But the query returns "no rows foud"... do you know what I am doing
wrong????
>
> SUSE LINUX Enterprise 11
> IDS 12.10.FC1
>
> Thanks for ur attention.
>
>
>
>
>
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30343]
*******************************************************************************
↧
Continuous Log Restore
Hi,
We are running Informix 11.50.FC6. Does anyone know if we can have a 2nd
instance in Continuous Log Restore via onbar, though have it at a set so it
will always be 4 hours behind the primary server?
Any ideas?
Thank You,
--Dave
--001a11c36e52d45fab04dd7973e7
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30344]
*******************************************************************************
↧
RE: Continuous Log Restore
Hello.
The easiest way to implement will be using an RSS server, aplying the
DELAY_APPLY feature.
It will automatically aply the delta you specify, and control the remaining
traffic.
http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.adref.doc/ids_adr_1069.htm?resultof=%22%44%45%4c%41%59%22%20%22%64%65%6c%61%69%22%20
Hope it helps.
Regards.
Alexandre Marini
IBM Informix Certified Professional v10 / v11.50 / v11.70
IBM Information Management Informix Technical Professional
IBM Infosphere DataStage Technical Professional
Informix Senior DBA - Orizon Brasil
BRIUG website administrator
Informix independent consultant
> To: ids@iiug.org
> From: in4mixdba@gmail.com
> Subject: Continuous Log Restore [30344]
> Date: Fri, 24 May 2013 12:40:24 -0400
>
> Hi,
>
> We are running Informix 11.50.FC6. Does anyone know if we can have a 2nd
> instance in Continuous Log Restore via onbar, though have it at a set so it
> will always be 4 hours behind the primary server?
>
> Any ideas?
>
> Thank You,
>
> --Dave
>
> --001a11c36e52d45fab04dd7973e7
>
>
>
>
>
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30345]
*******************************************************************************
↧
RE: How tu use a table on another Instance
Hmmm you sure are about that
On my workgroup 11.70
Select *
From oninit@theoden:users a, oninit@gimli:users b, custdb@custsite:users c
Where a.uid = b.uid
And a.uid = c.uid
Works happenly
Cheers
Paul
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Monday, May 27, 2013 4:07 PM
To: ids@iiug.org
Subject: Re: How tu use a table on another Instance [30350]
The only caviat is that only enterprise edition supports distributed
queries!
The alternative, if you are using Growth/Workgroup Edition, Innovator
Edition, or Express Edition, would be to use ER to replicate the table to
the HDR pair.
Art
On May 27, 2013 4:03 PM, "Marcus Haarmann"<marcus.haarmann@midoco.de>
wrote:
> Hi,
>
> you should be able to query the table using the syntax
> select field1, field2 ... from database@instance_z:table ...
> If the instance_z is in your sqlhosts of instance y and z trusts y
> (hosts.equiv or .rhosts e.g).
> Direct access can be tested with dbaccess (dbaccess
database@instance_zshould
> work directly
> from y machine).
>
> Marcus
>
> ----- Ursprüngliche Mail -----
>
> Von: "SMITH JOHN"<daylight@webmails.com>
> An: ids@iiug.org
> Gesendet: Montag, 27. Mai 2013 21:22:31
> Betreff: How tu use a table on another Instance [30348]
>
> Hi,
>
> I have my instance (11.50) "x" replicated with hdr "y", i made a third ids
> server "z" that contains a table which i want to acces from the "y"> server, so
> what are the steps to do so, please ?
>
> thanks in advance
>
>
>
>
****************************************************************************
***
>
>
>
>
>
****************************************************************************
***
>
>
>
--089e0117749dac969404ddb9851a
****************************************************************************
***
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30353]
*******************************************************************************
↧
↧
Re: How tu use a table on another Instance
Cool. Then you are good to go.
Art
On May 27, 2013 5:24 PM, "SMITH JOHN"<daylight@webmails.com> wrote:
> i forgot to tell that i have the ultimate version :)
>
>
>
>
>
>
>
--001a11c33ffc930f1504ddba18dc
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30354]
*******************************************************************************
↧
RE: How tu use a table on another Instance
According to the edition feature list tgat Carlton put together it's not
supported/permitted.
Art
On May 27, 2013 5:25 PM, "Paul Watson"<paul@oninit.com> wrote:
> Hmmm you sure are about that
>
> On my workgroup 11.70
>
> Select *
> >From oninit@theoden:users a, oninit@gimli:users b, custdb@custsite:users
> c
> Where a.uid = b.uid
> And a.uid = c.uid
>
> Works happenly
>
> Cheers
> Paul
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Monday, May 27, 2013 4:07 PM
> To: ids@iiug.org
> Subject: Re: How tu use a table on another Instance [30350]
>
> The only caviat is that only enterprise edition supports distributed
> queries!
>
> The alternative, if you are using Growth/Workgroup Edition, Innovator
> Edition, or Express Edition, would be to use ER to replicate the table to
> the HDR pair.
>
> Art
> On May 27, 2013 4:03 PM, "Marcus Haarmann"<marcus.haarmann@midoco.de>
> wrote:
>
> > Hi,
> >
> > you should be able to query the table using the syntax
> > select field1, field2 ... from database@instance_z:table ...
> > If the instance_z is in your sqlhosts of instance y and z trusts y
> > (hosts.equiv or .rhosts e.g).
> > Direct access can be tested with dbaccess (dbaccess
> database@instance_zshould
> > work directly
> > from y machine).
> >
> > Marcus
> >
> > ----- Ursprüngliche Mail -----
> >
> > Von: "SMITH JOHN"<daylight@webmails.com>
> > An: ids@iiug.org
> > Gesendet: Montag, 27. Mai 2013 21:22:31
> > Betreff: How tu use a table on another Instance [30348]
> >
> > Hi,
> >
> > I have my instance (11.50) "x" replicated with hdr "y", i made a third
> ids
>
> > server "z" that contains a table which i want to acces from the "y"> > server, so
> > what are the steps to do so, please ?
> >
> > thanks in advance
> >
> >
> >
> >
>
> ****************************************************************************
> ***
> >
> >
> >
> >
> >
>
> ****************************************************************************
> ***
> >
> >
> >
>
> --089e0117749dac969404ddb9851a
>
>
> ****************************************************************************
> ***
>
>
>
>
>
>
>
>
--001a11c33ffc5865b304ddba2281
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30355]
*******************************************************************************
↧
Re: How tu use a table on another Instance
Wow that has been a part of informix since forever - a show stopper for many I
should think
Cheers
Paul
Paul Watson
Oninit www.oninit.com
+1 913 387 7529
On May 27, 2013, at 16:50, "Art Kagel"<art.kagel@gmail.com> wrote:
> According to the edition feature list tgat Carlton put together it's not
> supported/permitted.
>
> Art
> On May 27, 2013 5:25 PM, "Paul Watson"<paul@oninit.com> wrote:
>
>> Hmmm you sure are about that
>>
>> On my workgroup 11.70
>>
>> Select *
>>> From oninit@theoden:users a, oninit@gimli:users b, custdb@custsite:users
>> c
>> Where a.uid = b.uid
>> And a.uid = c.uid
>>
>> Works happenly
>>
>> Cheers
>> Paul
>>
>> -----Original Message-----
>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
>> Kagel
>> Sent: Monday, May 27, 2013 4:07 PM
>> To: ids@iiug.org
>> Subject: Re: How tu use a table on another Instance [30350]
>>
>> The only caviat is that only enterprise edition supports distributed
>> queries!
>>
>> The alternative, if you are using Growth/Workgroup Edition, Innovator
>> Edition, or Express Edition, would be to use ER to replicate the table to
>> the HDR pair.
>>
>> Art
>> On May 27, 2013 4:03 PM, "Marcus Haarmann"<marcus.haarmann@midoco.de>
>> wrote:
>>
>>> Hi,
>>>
>>> you should be able to query the table using the syntax
>>> select field1, field2 ... from database@instance_z:table ...
>>> If the instance_z is in your sqlhosts of instance y and z trusts y
>>> (hosts.equiv or .rhosts e.g).
>>> Direct access can be tested with dbaccess (dbaccess
>> database@instance_zshould
>>> work directly
>>> from y machine).
>>>
>>> Marcus
>>>
>>> ----- Ursprüngliche Mail -----
>>>
>>> Von: "SMITH JOHN"<daylight@webmails.com>
>>> An: ids@iiug.org
>>> Gesendet: Montag, 27. Mai 2013 21:22:31
>>> Betreff: How tu use a table on another Instance [30348]
>>>
>>> Hi,
>>>
>>> I have my instance (11.50) "x" replicated with hdr "y", i made a third
>> ids
>>
>>> server "z" that contains a table which i want to acces from the "y">>> server, so
>>> what are the steps to do so, please ?
>>>
>>> thanks in advance
>>
>>
****************************************************************************
>> ***
>>>
>>
>>
****************************************************************************
>> ***
>>>
>>
>> --089e0117749dac969404ddb9851a
>>
>>
>>
****************************************************************************
>> ***
>>
>
>>
>
> --001a11c33ffc5865b304ddba2281
>
>
>
>
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30356]
*******************************************************************************
↧
Re: How tu use a table on another Instance
Aren't we confusing distributed queries and distributed/grid queries - the
later would need the ultimate/enterprise/whatever it is call this week version
AFAIK Marketing didn't like grid queries and called them distributed queries -
some thing that has always been there - nothing like presenting a clear image
:-)
Cheers
Paul
Paul Watson
Oninit www.oninit.com
+1 913 387 7529
On May 27, 2013, at 16:57, Paul Watson <paul@oninit.com> wrote:
> Wow that has been a part of informix since forever - a show stopper for many
I should think
>
> Cheers
> Paul
>
> Paul Watson
> Oninit www.oninit.com
> +1 913 387 7529
>
>
> On May 27, 2013, at 16:50, "Art Kagel"<art.kagel@gmail.com> wrote:
>
>> According to the edition feature list tgat Carlton put together it's not
>> supported/permitted.
>>
>> Art
>> On May 27, 2013 5:25 PM, "Paul Watson"<paul@oninit.com> wrote:
>>
>>> Hmmm you sure are about that
>>>
>>> On my workgroup 11.70
>>>
>>> Select *
>>>> From oninit@theoden:users a, oninit@gimli:users b, custdb@custsite:users
>>> c
>>> Where a.uid = b.uid
>>> And a.uid = c.uid
>>>
>>> Works happenly
>>>
>>> Cheers
>>> Paul
>>>
>>> -----Original Message-----
>>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
>>> Kagel
>>> Sent: Monday, May 27, 2013 4:07 PM
>>> To: ids@iiug.org
>>> Subject: Re: How tu use a table on another Instance [30350]
>>>
>>> The only caviat is that only enterprise edition supports distributed
>>> queries!
>>>
>>> The alternative, if you are using Growth/Workgroup Edition, Innovator
>>> Edition, or Express Edition, would be to use ER to replicate the table to
>>> the HDR pair.
>>>
>>> Art
>>> On May 27, 2013 4:03 PM, "Marcus Haarmann"<marcus.haarmann@midoco.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> you should be able to query the table using the syntax
>>>> select field1, field2 ... from database@instance_z:table ...
>>>> If the instance_z is in your sqlhosts of instance y and z trusts y
>>>> (hosts.equiv or .rhosts e.g).
>>>> Direct access can be tested with dbaccess (dbaccess
>>> database@instance_zshould
>>>> work directly
>>>> from y machine).
>>>>
>>>> Marcus
>>>>
>>>> ----- Ursprüngliche Mail -----
>>>>
>>>> Von: "SMITH JOHN"<daylight@webmails.com>
>>>> An: ids@iiug.org
>>>> Gesendet: Montag, 27. Mai 2013 21:22:31
>>>> Betreff: How tu use a table on another Instance [30348]
>>>>
>>>> Hi,
>>>>
>>>> I have my instance (11.50) "x" replicated with hdr "y", i made a third
>>> ids
>>>
>>>> server "z" that contains a table which i want to acces from the "y">>>> server, so
>>>> what are the steps to do so, please ?
>>>>
>>>> thanks in advance
>>>
>>>
****************************************************************************
>>> ***
>>>>
>>>
>>>
****************************************************************************
>>> ***
>>>>
>>>
>>> --089e0117749dac969404ddb9851a
>>>
>>>
>>>
****************************************************************************
>>> ***
>>>
>>
>>>
>>
>> --001a11c33ffc5865b304ddba2281
>>
>>
>>
>>
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30357]
*******************************************************************************
↧
↧
Re: How tu use a table on another Instance
No. The nee festure is now called Sharded Queries.
Art
On May 27, 2013 6:27 PM, "Paul Watson"<paul@oninit.com> wrote:
> Aren't we confusing distributed queries and distributed/grid queries - the
> later would need the ultimate/enterprise/whatever it is call this week
> version
>
> AFAIK Marketing didn't like grid queries and called them distributed
> queries -
> some thing that has always been there - nothing like presenting a clear
> image
> :-)
>
> Cheers
> Paul
>
> Paul Watson
> Oninit www.oninit.com
> +1 913 387 7529
>
> On May 27, 2013, at 16:57, Paul Watson <paul@oninit.com> wrote:
>
> > Wow that has been a part of informix since forever - a show stopper for
> many
> I should think
> >
> > Cheers
> > Paul
> >
> > Paul Watson
> > Oninit www.oninit.com
> > +1 913 387 7529
> >
> >
> > On May 27, 2013, at 16:50, "Art Kagel"<art.kagel@gmail.com> wrote:
> >
> >> According to the edition feature list tgat Carlton put together it's not
> >> supported/permitted.
> >>
> >> Art
> >> On May 27, 2013 5:25 PM, "Paul Watson"<paul@oninit.com> wrote:
> >>
> >>> Hmmm you sure are about that
> >>>
> >>> On my workgroup 11.70
> >>>
> >>> Select *
> >>>> From oninit@theoden:users a, oninit@gimli:users b, custdb@custsite
> :users
> >>> c
> >>> Where a.uid = b.uid
> >>> And a.uid = c.uid
> >>>
> >>> Works happenly
> >>>
> >>> Cheers
> >>> Paul
> >>>
> >>> -----Original Message-----
> >>> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art
> >>> Kagel
> >>> Sent: Monday, May 27, 2013 4:07 PM
> >>> To: ids@iiug.org
> >>> Subject: Re: How tu use a table on another Instance [30350]
> >>>
> >>> The only caviat is that only enterprise edition supports distributed
> >>> queries!
> >>>
> >>> The alternative, if you are using Growth/Workgroup Edition, Innovator
> >>> Edition, or Express Edition, would be to use ER to replicate the table
> to
> >>> the HDR pair.
> >>>
> >>> Art
> >>> On May 27, 2013 4:03 PM, "Marcus Haarmann"<marcus.haarmann@midoco.de>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> you should be able to query the table using the syntax
> >>>> select field1, field2 ... from database@instance_z:table ...
> >>>> If the instance_z is in your sqlhosts of instance y and z trusts y
> >>>> (hosts.equiv or .rhosts e.g).
> >>>> Direct access can be tested with dbaccess (dbaccess
> >>> database@instance_zshould
> >>>> work directly
> >>>> from y machine).
> >>>>
> >>>> Marcus
> >>>>
> >>>> ----- Ursprüngliche Mail -----
> >>>>
> >>>> Von: "SMITH JOHN"<daylight@webmails.com>
> >>>> An: ids@iiug.org
> >>>> Gesendet: Montag, 27. Mai 2013 21:22:31
> >>>> Betreff: How tu use a table on another Instance [30348]
> >>>>
> >>>> Hi,
> >>>>
> >>>> I have my instance (11.50) "x" replicated with hdr "y", i made a third
> >>> ids
> >>>
> >>>> server "z" that contains a table which i want to acces from the "y"> >>>> server, so
> >>>> what are the steps to do so, please ?
> >>>>
> >>>> thanks in advance
> >>>
> >>>
>
> ****************************************************************************
> >>> ***
> >>>>
> >>>
> >>>
>
> ****************************************************************************
> >>> ***
> >>>>
> >>>
> >>> --089e0117749dac969404ddb9851a
> >>>
> >>>
> >>>
>
> ****************************************************************************
> >>> ***
> >>>
> >>
>
>
> >>>
> >>
> >> --001a11c33ffc5865b304ddba2281
> >>
> >>
> >>
>
>
> >>
>
>
>
>
>
>
>
--089e0158ad545407cb04ddbad24a
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30358]
*******************************************************************************
↧
Violations Tables - IFX 11.70
Hi Guys,
We have an application which occasionally ends up inserting duplicate data
into a table (not ideal I know).
We use the Informix violations table to work around this problem.
This works well, but occasionally (twice a year?) violations tables seem to
stop working.
We need run something like this to fix it.
drop table items_vio;
drop table items_dia;
START VIOLATIONS TABLE FOR items;
SET CONSTRAINTS FOR items FILTERING WITHOUT ERROR;
Any ideas what would cause it?
Is there some admin tasks or something that might do it? Restarting the
engine? Or is it just a bug?
I'm sure there weren't any schema changes to that table.
IBM Informix Dynamic Server Version 11.70.FC2GE
Redhat Linux 5
Cheers,
James Brunskill
[cid:image001.jpg@01CE5B87.FFA50340]
Process Information Lead
Fonterra Co-operative Group Limited
james.brunskill@fonterra.com<mailto:james.brunskill@fonterra.com>
Phone: +64 7 850 7738 (ext 77808)
Mobile: +64 21 2400 215
MES Support: +64 7 849 7895
Fonterra Co-operative Group Limited
PO Box 459, Hamilton, 3240, Automation and Process Control, Fonterra Te Rapa,
SH1, Hamilton, New Zealand
[cid:image002.png@01CE5B87.FFA50340]
________________________________
DISCLAIMER
This email contains information that is confidential and which may be legally
privileged. If you have received this email in error, please notify the sender
immediately and delete the email. This email is intended solely for the use of
the intended recipient and you may not use or disclose this email in any way.
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30359]
*******************************************************************************
↧
Re: Violations Tables - IFX 11.70
Why not just put a unique index/constraint on the table and end the problem
altogether?
Art
On May 27, 2013 6:56 PM, "James Brunskill"<James.Brunskill@fonterra.com>
wrote:
> Hi Guys,
>
> We have an application which occasionally ends up inserting duplicate data
> into a table (not ideal I know).
>
> We use the Informix violations table to work around this problem.
>
> This works well, but occasionally (twice a year?) violations tables seem to
> stop working.
> We need run something like this to fix it.
>
> drop table items_vio;
> drop table items_dia;
> START VIOLATIONS TABLE FOR items;
> SET CONSTRAINTS FOR items FILTERING WITHOUT ERROR;
>
> Any ideas what would cause it?
> Is there some admin tasks or something that might do it? Restarting the
> engine? Or is it just a bug?
>
> I'm sure there weren't any schema changes to that table.
>
> IBM Informix Dynamic Server Version 11.70.FC2GE
> Redhat Linux 5
>
> Cheers,
>
> James Brunskill
>
> [cid:image001.jpg@01CE5B87.FFA50340]
>
> Process Information Lead
> Fonterra Co-operative Group Limited
>
> james.brunskill@fonterra.com<mailto:james.brunskill@fonterra.com>
> Phone: +64 7 850 7738 (ext 77808)
> Mobile: +64 21 2400 215
> MES Support: +64 7 849 7895
> Fonterra Co-operative Group Limited
> PO Box 459, Hamilton, 3240, Automation and Process Control, Fonterra Te
> Rapa,
> SH1, Hamilton, New Zealand
>
> [cid:image002.png@01CE5B87.FFA50340]
>
> ________________________________
> DISCLAIMER
> This email contains information that is confidential and which may be
> legally
> privileged. If you have received this email in error, please notify the
> sender
> immediately and delete the email. This email is intended solely for the
> use of
> the intended recipient and you may not use or disclose this email in any
> way.
>
>
>
>
>
>
>
--001a11c38a3e7f3a8304ddbb2932
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [30360]
*******************************************************************************
↧
More Pages to Explore .....
