Question about replicating stored procedure execution

I am doing some research in advance of setting up replication. I've
read about replicating stored procedure execution and I need
clarification on what it is exactly.
My understanding is that, for example, if you have a stored procedure
on the publisher that modifies 10,000 rows then replication will not
replicate the 10,000 modifications to the subscriber but will rather
pass along the execute command which will then be executed locally at
the subscriber. Do I have that correct?
Is this a common practice in a replication scenario?
Thanks
Exactly. Its not commonly used because most people don't know about it, and
secondly sometimes the tables referenced by the stored procedures are
different on the publisher and subscriber and therefore you get different
dml on either side.
Other people want the proc run within a serializable transaction for
consistency, which is another option. Is the proc is not run within a
serializable transaction, the DML is replicated instead of the proc.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<pshroads@.gmail.com> wrote in message
news:1139532907.083047.89490@.z14g2000cwz.googlegro ups.com...
>I am doing some research in advance of setting up replication. I've
> read about replicating stored procedure execution and I need
> clarification on what it is exactly.
> My understanding is that, for example, if you have a stored procedure
> on the publisher that modifies 10,000 rows then replication will not
> replicate the 10,000 modifications to the subscriber but will rather
> pass along the execute command which will then be executed locally at
> the subscriber. Do I have that correct?
> Is this a common practice in a replication scenario?
> Thanks
>
|||I have tried this feature and worked OK. I have a nightly purge job that
delete lots of data and the processes can be separately on each server (it is
based on creation timestamp of the rows, which was replicated). My
situation, this worked well. I think the serialization consistency will only
gnerate more locks.
However, I ran into problem when try to verify the replication. It treated
the SP as a table and verification failed. Try it, see if you got the same
error. Thk !!

question about linked servers and Access tables

Having a little problem with linking to Access tables. I have an Access database that has in it, some linked tables. After setting up the linked server in SQL server, none of the linked tables in Access show up, only the tables that were created or imported show up.

Is there anything you can do to get the linked tables in Access to show up under the tables list in the SQL linked server?Can you query the Access table(s) using the 4 part naming convention?

select * from <server>.<db>.<owner>.<table>

|||haven't tried that, didn't consider it since the tables do not show up. but will give it a shot.|||Got an error saying the file was open exclusively by another or i dont have permissions, which is not the case. The linked tables are from an Oracle database. So the permission problem might be with it.

Question about ISOLATION LEVEL.

(SQL Server 2000, SP3a)
Hello, all!
I've got a question about setting the transaction isolation level within a stored
procedure.
In essence I want to have a particular piece of code in a SP use the SERIALIZABLE level.
However, I don't want this to "stick" for the rest of the connection as this BOL blurb
suggests:
<Quote>
Only one of the options can be set at a time, and it remains set for that connection until
it is explicitly changed. This becomes the default behavior unless an optimization option
is specified at the table level in the FROM clause of the statement.
<Quote>
Does the specified level really persist even if it's been invoked from a SP? Is there any
way to get the "old" level if I change it?
Alternatively, I *think* I could put this in the FROM clause (can it be in the
<table_hint_limited> section of an UPDATE instead?):
update mt with (rowlock, readcommitted)
set MyField = 1
from MyTable as mt
where MyField = 2
Or does it have to be in the FROM clause like:
update mt with (rowlock)
set MyField = 1
from MyTable as mt with (readcommitted)
where MyField = 2
Or does it matter?
Thanks for any help you can provide! :-)
John PetersonJohn,
It will stay that way for the life of the connection if you don't change it.
But why don't you just issue a SET TRANSACTION ISOLATION LEVEL Read
Committed when done?
--
Andrew J. Kelly
SQL Server MVP
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:OkRbjfWfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello, all!
> I've got a question about setting the transaction isolation level within a
stored
> procedure.
> In essence I want to have a particular piece of code in a SP use the
SERIALIZABLE level.
> However, I don't want this to "stick" for the rest of the connection as
this BOL blurb
> suggests:
> <Quote>
> Only one of the options can be set at a time, and it remains set for that
connection until
> it is explicitly changed. This becomes the default behavior unless an
optimization option
> is specified at the table level in the FROM clause of the statement.
> <Quote>
> Does the specified level really persist even if it's been invoked from a
SP? Is there any
> way to get the "old" level if I change it?
>
> Alternatively, I *think* I could put this in the FROM clause (can it be in
the
> <table_hint_limited> section of an UPDATE instead?):
> update mt with (rowlock, readcommitted)
> set MyField = 1
> from MyTable as mt
> where MyField = 2
> Or does it have to be in the FROM clause like:
> update mt with (rowlock)
> set MyField = 1
> from MyTable as mt with (readcommitted)
> where MyField = 2
> Or does it matter?
> Thanks for any help you can provide! :-)
> John Peterson
>|||From the SQL Server 2000 Books Online:
<Excerpt href="http://links.10026.com/?link=tsqlref.chm::/ts_create_4hk5.htm">
When a SET statement is executed from a stored procedure, the setting
remains in effect only until the stored procedure completes. The setting
is then restored to the value it had when the stored procedure was
called. This allows individual clients to set the options wanted without
affecting the logic of the stored procedure.
</Excerpt>
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:OkRbjfWfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello, all!
> I've got a question about setting the transaction isolation level
within a stored
> procedure.
> In essence I want to have a particular piece of code in a SP use the
SERIALIZABLE level.
> However, I don't want this to "stick" for the rest of the connection
as this BOL blurb
> suggests:
> <Quote>
> Only one of the options can be set at a time, and it remains set for
that connection until
> it is explicitly changed. This becomes the default behavior unless an
optimization option
> is specified at the table level in the FROM clause of the statement.
> <Quote>
> Does the specified level really persist even if it's been invoked from
a SP? Is there any
> way to get the "old" level if I change it?
>
> Alternatively, I *think* I could put this in the FROM clause (can it
be in the
> <table_hint_limited> section of an UPDATE instead?):
> update mt with (rowlock, readcommitted)
> set MyField = 1
> from MyTable as mt
> where MyField = 2
> Or does it have to be in the FROM clause like:
> update mt with (rowlock)
> set MyField = 1
> from MyTable as mt with (readcommitted)
> where MyField = 2
> Or does it matter?
> Thanks for any help you can provide! :-)
> John Peterson
>|||Dan,
It's my understanding that this does not hold true for the Isolation level
and it is retained for the entire session or until it is changed again. I
guess I will have to test this to see...
--
Andrew J. Kelly
SQL Server MVP
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:OlGwpUXfDHA.3284@.tk2msftngp13.phx.gbl...
> From the SQL Server 2000 Books Online:
> <Excerpt href="http://links.10026.com/?link=tsqlref.chm::/ts_create_4hk5.htm">
> When a SET statement is executed from a stored procedure, the setting
> remains in effect only until the stored procedure completes. The setting
> is then restored to the value it had when the stored procedure was
> called. This allows individual clients to set the options wanted without
> affecting the logic of the stored procedure.
> </Excerpt>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> --
> SQL FAQ links (courtesy Neil Pike):
> http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> http://www.sqlserverfaq.com
> http://www.mssqlserver.com/faq
> --
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:OkRbjfWfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> > (SQL Server 2000, SP3a)
> >
> > Hello, all!
> >
> > I've got a question about setting the transaction isolation level
> within a stored
> > procedure.
> >
> > In essence I want to have a particular piece of code in a SP use the
> SERIALIZABLE level.
> > However, I don't want this to "stick" for the rest of the connection
> as this BOL blurb
> > suggests:
> >
> > <Quote>
> > Only one of the options can be set at a time, and it remains set for
> that connection until
> > it is explicitly changed. This becomes the default behavior unless an
> optimization option
> > is specified at the table level in the FROM clause of the statement.
> > <Quote>
> >
> > Does the specified level really persist even if it's been invoked from
> a SP? Is there any
> > way to get the "old" level if I change it?
> >
> >
> > Alternatively, I *think* I could put this in the FROM clause (can it
> be in the
> > <table_hint_limited> section of an UPDATE instead?):
> >
> > update mt with (rowlock, readcommitted)
> > set MyField = 1
> > from MyTable as mt
> > where MyField = 2
> >
> > Or does it have to be in the FROM clause like:
> >
> > update mt with (rowlock)
> > set MyField = 1
> > from MyTable as mt with (readcommitted)
> > where MyField = 2
> >
> > Or does it matter?
> >
> > Thanks for any help you can provide! :-)
> >
> > John Peterson
> >
> >
>|||Andrew, I ran the follow script to verify the BOL statement and it
seemed to held true, at least as reported by DBCC USEROPTIONS.
CREATE PROC MyProc
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
DBCC USEROPTIONS
GO
DBCC USEROPTIONS
EXEC MyProc
DBCC USEROPTIONS
GO
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:O3ziOFYfDHA.2352@.TK2MSFTNGP12.phx.gbl...
> Dan,
> It's my understanding that this does not hold true for the Isolation
level
> and it is retained for the entire session or until it is changed
again. I
> guess I will have to test this to see...
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> news:OlGwpUXfDHA.3284@.tk2msftngp13.phx.gbl...
> > From the SQL Server 2000 Books Online:
> >
> > <Excerpt href="http://links.10026.com/?link=tsqlref.chm::/ts_create_4hk5.htm">
> > When a SET statement is executed from a stored procedure, the
setting
> > remains in effect only until the stored procedure completes. The
setting
> > is then restored to the value it had when the stored procedure was
> > called. This allows individual clients to set the options wanted
without
> > affecting the logic of the stored procedure.
> > </Excerpt>
> >
> > --
> > Hope this helps.
> >
> > Dan Guzman
> > SQL Server MVP
> >
> > --
> > SQL FAQ links (courtesy Neil Pike):
> >
> > http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> > http://www.sqlserverfaq.com
> > http://www.mssqlserver.com/faq
> > --
> >
> > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > news:OkRbjfWfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> > > (SQL Server 2000, SP3a)
> > >
> > > Hello, all!
> > >
> > > I've got a question about setting the transaction isolation level
> > within a stored
> > > procedure.
> > >
> > > In essence I want to have a particular piece of code in a SP use
the
> > SERIALIZABLE level.
> > > However, I don't want this to "stick" for the rest of the
connection
> > as this BOL blurb
> > > suggests:
> > >
> > > <Quote>
> > > Only one of the options can be set at a time, and it remains set
for
> > that connection until
> > > it is explicitly changed. This becomes the default behavior unless
an
> > optimization option
> > > is specified at the table level in the FROM clause of the
statement.
> > > <Quote>
> > >
> > > Does the specified level really persist even if it's been invoked
from
> > a SP? Is there any
> > > way to get the "old" level if I change it?
> > >
> > >
> > > Alternatively, I *think* I could put this in the FROM clause (can
it
> > be in the
> > > <table_hint_limited> section of an UPDATE instead?):
> > >
> > > update mt with (rowlock, readcommitted)
> > > set MyField = 1
> > > from MyTable as mt
> > > where MyField = 2
> > >
> > > Or does it have to be in the FROM clause like:
> > >
> > > update mt with (rowlock)
> > > set MyField = 1
> > > from MyTable as mt with (readcommitted)
> > > where MyField = 2
> > >
> > > Or does it matter?
> > >
> > > Thanks for any help you can provide! :-)
> > >
> > > John Peterson
> > >
> > >
> >
> >
>|||Thanks guys, that helps! I didn't see that blurb, Dan -- can you tell me what section of
BOL you found that?
As it turns out, I decided to do it at the table level as in my example. Curiously, I had
READCOMMITTED at *both* the UPDATE clause and the FROM clause. That turned out to be
rather "heavy" for some reason. When I changed it to be just on the UPDATE clause, it was
substantially faster.
Thanks again!
John Peterson
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:OnDkGhYfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> Andrew, I ran the follow script to verify the BOL statement and it
> seemed to held true, at least as reported by DBCC USEROPTIONS.
> CREATE PROC MyProc
> AS
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> DBCC USEROPTIONS
> GO
> DBCC USEROPTIONS
> EXEC MyProc
> DBCC USEROPTIONS
> GO
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:O3ziOFYfDHA.2352@.TK2MSFTNGP12.phx.gbl...
> > Dan,
> >
> > It's my understanding that this does not hold true for the Isolation
> level
> > and it is retained for the entire session or until it is changed
> again. I
> > guess I will have to test this to see...
> >
> > --
> >
> > Andrew J. Kelly
> > SQL Server MVP
> >
> >
> > "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> > news:OlGwpUXfDHA.3284@.tk2msftngp13.phx.gbl...
> > > From the SQL Server 2000 Books Online:
> > >
> > > <Excerpt href="http://links.10026.com/?link=tsqlref.chm::/ts_create_4hk5.htm">
> > > When a SET statement is executed from a stored procedure, the
> setting
> > > remains in effect only until the stored procedure completes. The
> setting
> > > is then restored to the value it had when the stored procedure was
> > > called. This allows individual clients to set the options wanted
> without
> > > affecting the logic of the stored procedure.
> > > </Excerpt>
> > >
> > > --
> > > Hope this helps.
> > >
> > > Dan Guzman
> > > SQL Server MVP
> > >
> > > --
> > > SQL FAQ links (courtesy Neil Pike):
> > >
> > > http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> > > http://www.sqlserverfaq.com
> > > http://www.mssqlserver.com/faq
> > > --
> > >
> > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > news:OkRbjfWfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> > > > (SQL Server 2000, SP3a)
> > > >
> > > > Hello, all!
> > > >
> > > > I've got a question about setting the transaction isolation level
> > > within a stored
> > > > procedure.
> > > >
> > > > In essence I want to have a particular piece of code in a SP use
> the
> > > SERIALIZABLE level.
> > > > However, I don't want this to "stick" for the rest of the
> connection
> > > as this BOL blurb
> > > > suggests:
> > > >
> > > > <Quote>
> > > > Only one of the options can be set at a time, and it remains set
> for
> > > that connection until
> > > > it is explicitly changed. This becomes the default behavior unless
> an
> > > optimization option
> > > > is specified at the table level in the FROM clause of the
> statement.
> > > > <Quote>
> > > >
> > > > Does the specified level really persist even if it's been invoked
> from
> > > a SP? Is there any
> > > > way to get the "old" level if I change it?
> > > >
> > > >
> > > > Alternatively, I *think* I could put this in the FROM clause (can
> it
> > > be in the
> > > > <table_hint_limited> section of an UPDATE instead?):
> > > >
> > > > update mt with (rowlock, readcommitted)
> > > > set MyField = 1
> > > > from MyTable as mt
> > > > where MyField = 2
> > > >
> > > > Or does it have to be in the FROM clause like:
> > > >
> > > > update mt with (rowlock)
> > > > set MyField = 1
> > > > from MyTable as mt with (readcommitted)
> > > > where MyField = 2
> > > >
> > > > Or does it matter?
> > > >
> > > > Thanks for any help you can provide! :-)
> > > >
> > > > John Peterson
> > > >
> > > >
> > >
> > >
> >
> >
>|||> Dan -- can you tell me what section of
> BOL you found that?
The excerpt is from the CREATE PROCEDURE topic. You can jump there
directly from the Bools Online menu bar by clicking Go --> URL and
pasting in 'tsqlref.chm::/ts_create_4hk5.htm'.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:%23RXiFnYfDHA.1760@.TK2MSFTNGP09.phx.gbl...
> Thanks guys, that helps! I didn't see that blurb, Dan -- can you tell
me what section of
> BOL you found that?
> As it turns out, I decided to do it at the table level as in my
example. Curiously, I had
> READCOMMITTED at *both* the UPDATE clause and the FROM clause. That
turned out to be
> rather "heavy" for some reason. When I changed it to be just on the
UPDATE clause, it was
> substantially faster.
> Thanks again!
> John Peterson
>|||"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%238x$R8dfDHA.1200@.TK2MSFTNGP09.phx.gbl...
> Hmmm. Thanks Dan. I was pretty sure that I remember reading otherwise
> somewhere so that's good to know. Not that I ever set an isolation level
> without setting it back anyway.
The problem with setting it back, IMO, is that there's not a convenient mechanism to
record the *old* isolation level with which to restore. Granted, 99.99% of the time it's
likely the default of READ COMMITTED. But we've got some clients whose default is
essentially READ UNCOMMITTED.
> Andrew J. Kelly
> SQL Server MVP
>
> "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> news:OnDkGhYfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> > Andrew, I ran the follow script to verify the BOL statement and it
> > seemed to held true, at least as reported by DBCC USEROPTIONS.
> >
> > CREATE PROC MyProc
> > AS
> > SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> > DBCC USEROPTIONS
> > GO
> >
> > DBCC USEROPTIONS
> > EXEC MyProc
> > DBCC USEROPTIONS
> > GO
> >
> > --
> > Hope this helps.
> >
> > Dan Guzman
> > SQL Server MVP
> >
> >
> > "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> > news:O3ziOFYfDHA.2352@.TK2MSFTNGP12.phx.gbl...
> > > Dan,
> > >
> > > It's my understanding that this does not hold true for the Isolation
> > level
> > > and it is retained for the entire session or until it is changed
> > again. I
> > > guess I will have to test this to see...
> > >
> > > --
> > >
> > > Andrew J. Kelly
> > > SQL Server MVP
> > >
> > >
> > > "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> > > news:OlGwpUXfDHA.3284@.tk2msftngp13.phx.gbl...
> > > > From the SQL Server 2000 Books Online:
> > > >
> > > > <Excerpt href="http://links.10026.com/?link=tsqlref.chm::/ts_create_4hk5.htm">
> > > > When a SET statement is executed from a stored procedure, the
> > setting
> > > > remains in effect only until the stored procedure completes. The
> > setting
> > > > is then restored to the value it had when the stored procedure was
> > > > called. This allows individual clients to set the options wanted
> > without
> > > > affecting the logic of the stored procedure.
> > > > </Excerpt>
> > > >
> > > > --
> > > > Hope this helps.
> > > >
> > > > Dan Guzman
> > > > SQL Server MVP
> > > >
> > > > --
> > > > SQL FAQ links (courtesy Neil Pike):
> > > >
> > > > http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> > > > http://www.sqlserverfaq.com
> > > > http://www.mssqlserver.com/faq
> > > > --
> > > >
> > > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > > news:OkRbjfWfDHA.1732@.TK2MSFTNGP12.phx.gbl...
> > > > > (SQL Server 2000, SP3a)
> > > > >
> > > > > Hello, all!
> > > > >
> > > > > I've got a question about setting the transaction isolation level
> > > > within a stored
> > > > > procedure.
> > > > >
> > > > > In essence I want to have a particular piece of code in a SP use
> > the
> > > > SERIALIZABLE level.
> > > > > However, I don't want this to "stick" for the rest of the
> > connection
> > > > as this BOL blurb
> > > > > suggests:
> > > > >
> > > > > <Quote>
> > > > > Only one of the options can be set at a time, and it remains set
> > for
> > > > that connection until
> > > > > it is explicitly changed. This becomes the default behavior unless
> > an
> > > > optimization option
> > > > > is specified at the table level in the FROM clause of the
> > statement.
> > > > > <Quote>
> > > > >
> > > > > Does the specified level really persist even if it's been invoked
> > from
> > > > a SP? Is there any
> > > > > way to get the "old" level if I change it?
> > > > >
> > > > >
> > > > > Alternatively, I *think* I could put this in the FROM clause (can
> > it
> > > > be in the
> > > > > <table_hint_limited> section of an UPDATE instead?):
> > > > >
> > > > > update mt with (rowlock, readcommitted)
> > > > > set MyField = 1
> > > > > from MyTable as mt
> > > > > where MyField = 2
> > > > >
> > > > > Or does it have to be in the FROM clause like:
> > > > >
> > > > > update mt with (rowlock)
> > > > > set MyField = 1
> > > > > from MyTable as mt with (readcommitted)
> > > > > where MyField = 2
> > > > >
> > > > > Or does it matter?
> > > > >
> > > > > Thanks for any help you can provide! :-)
> > > > >
> > > > > John Peterson
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>

Question about encryption and password protection

Howdy!

Couple quick questions:

1) How much does setting encryption cost in terms of speed of querying and cpu usage?
2) If encryption is not set, is the password "encrypted" when its sent with the initialization routine?

Thanks in advance!

1: Most agree on a 10 - 20 % performance hit (on devices), it is probably not noticeable on a desktop.

2: If a password is specifed, you are always using encryption

Password-or-Pwd-or-database password-or-ssceatabase password

The database password, which can be up to 40 characters in length. If not specified, the default value is no password. This property is required if you enable encryption on the database. If you specify a password, encryption is automatically enabled on the database.

|||Thanks for the reply!

Question : Transactional Replication Rollback ?

We have a sql2k db as a Distributor, with a few servers geographically
scattered acting as subscribers (backup). I'm setting up transaction
replication, however, is there a way to rollback in the event of
dataloss on the Distributor ?
Eg : 'delete tblProducts' run on the distributor. Wouldn't this
effectively delete tblProducts on every subscriber ? Is there anyway
to rollback in such an event.
Thanks,
Amit Chandel
Amit,
presumably when you say Distributor, you mean Publisher/Distributor?
If you run the TSQL "Delete * from Table1" on the publisher this will be
propagated via the logreader and distribution agents to the subscriber.
Turning off these agents before the command gets to the subscriber will
prevent the delete. Once it has occurred at the subscriber, you can not roll
it back. One posibility is you could back up the transaction log and do a
point-in-time restore. If the command is potentially 'dodgy' then you could
also wrap it in a transaction with normal error trapping and ROLLBACK
statements. If you give the transaction a name, it is possible to do a
restore as mentioned above, but not to a point in time, rather to just
before the named transaction was run.
HTH,
Paul Ibison