How to move MSSQL database to Oracle for a single customer?
Bo Berglund
using MSSQLServer, which we are very satisfied with. Good stuff!
But now we have this big potential customer who has an IT policy in
place that all databases in the organization *must* be Oracle based...
We are now asked to provide a ballpark figure on what the cost would
be to convert our system to use Oracle and we know very little about
Oracle so we are in a spot here.
Basically what I am looking for is *not* how to move data, but rather
how to implement our database system in Oracle.
We have some 100 tables with a lot of foreign keys and indexes and we
use TransactSQL procedures to do most of the work in the database. Our
applications in principle always use calls to stored procedures (via
ADO) to enter and read data and to perform some calculations.
There are *many* procedures!
We want to keep on working in MSSQLServer for future developments and
for all other customers, but this one is so big so we can't afford not
to at least investigate what is involved.
Our database is loaded into a new server entirely by running a set of
SQL scripts, which create the tables and all the indexes and keys and
also loads the stored procedures. They also populate system data into
a few tables.
I realize that this is probably not the right place to ask how to move
*from* MSSQLSERVER but in fact we do not want to do this except in
this specific case. So the migration must be done in such a way that
continued maintenance is possible on parallel platforms.
And I believe that here will be folks who have experience with
multiple platforms, right?
Any ideas, hints, weblinks etc are welcome! :-)
Bo Berglund
sloan
My suggestion (on the software side) is to do 2 things.
Move the the EnterpriseLibary.Data library.
AND
implement a Factory Pattern solution for you datalayer.
Let's take an EmployeeData (dal) class, that gets employees.
define an interface
public interface IEmployeeData
{
IDataReader GetAllEmployees();
}
public class EmployeeSqlServerData : IEmployeeData
IDataReader GetAllEmployees()
{
//create EnterpriseLibrary code/calls here to get a datareader from
SqlServer
}
}
public class EmployeeOracleData : IEmployeeData
IDataReader GetAllEmployees()
{
// //create EnterpriseLibrary code/calls here to get a
datareader from Oracle
}
}
The final piece
public class EmployeeDataFactory
{
private EmployeeDataFactory(){}
internal static IEmployeeData GetCorrectVendorEmployeeData( )
{
string rdbms = "Oracle"; //store it in a config file probably
if(rdbms.ToUpper() == "ORACLE")
{
return new EmployeeOracleData ();
}
//default
return new EmployeeSqlServerData ();
}
}
This will keep your code very very clean, and OO oriented.
As far as the in and outs of tables/indexes/stored procedures..... you'll
have two sets of .sql files.
The solution above will keep you flexible .
I've found that the Factory Pattern is very very good for different RDBMS
setups.
You ~can get by with just the EnterpriseLibrary, but requires a tremendous
amount of conistency in naming conventions between the two dbs.
The Factory Pattern allows for the perks of two different rdbms (Oracle and
Sql Server especially).
The way you load a (strong) dataset is so very different in Oracle (out ref
cursors) than it is in Sql Server, that is why I prefer a Factory Pattern
model instead.
Check my blog here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry
and go back to the main blog page... and you can find a Custom Business
Objects NLayered example.
Read my rules about what a datalayer SHOULD return.
You have stumbled upon a perfect situation where well layered development
AND using an OO pattern like the Factory can keep your code clean, the
solution elegant, and extendible for the future.
..
"Bo Berglund" <bober...@home.se> wrote in message
news:onp7g3ht4cukc8ght...@4ax.com...
sloan
Rereading your post, I guess I assumed some things.
Is your application written in DotNet?
// TransactSQL procedures to do most of the work in the database. Our
>> applications in principle always use calls to stored procedures (via
>> ADO) to enter and read data and to perform some calculations.
>> There are *many* procedures!//
ADO or ADO.Net?
If you using ADO and VB6... than, man you're in for it.
......
If you've written a majority of your business logic inside the procedures of
the database...than man... you're in for it.
"sloan" <sl...@ipass.net> wrote in message
news:epnwwUfB...@TK2MSFTNGP03.phx.gbl...
NigelA
the customer, they will not be happy. It will be a nightmare for you, you
will not be happy. T-SQL and PL SQL are very different beasts once you get
past basic selects and inserts so you will have to re-write ALL your stored
procedures. ADO will not work the way you want it to if at all so you will
need a new strategy and code base for that. If this potential customer is
all Oracle I would bet they are UNIX too which if you are a SQL Server shop
you do not have experience of. Oh and you will need an Oracle DBA at $800
dollars a day. And unless the customer is stupid they will know this and
know that the lower risk to themselves is to take your offering on the
platform it was written for.
If on the other hand you want to break into the Oracle market go ahead and
do a re-write of all your data access. Writing platform independent data
access layers is not trivial but can be done. Remember though you will
always have to maintain two code bases for your SPs, views and any other SQL
scripts.
Nigel Ainscoe
MBCS MCP
"Bo Berglund" <bober...@home.se> wrote in message
news:onp7g3ht4cukc8ght...@4ax.com...
Awlnoing
would not do business with any company so narrow minded. Secondly if your
business logic is in TSQL you face an uphill battle converting to PL SQL
because of some fundemental differences in rdbms behavior. Table structure
and data are relatively easy to move.
However, loving a challenge and portable code, I would move any logic beyond
select, insert, update, and delete into another language like .Net or Java
and then deploy a program that is theoretically plaftorm/db independent.
"Bo Berglund" <bober...@home.se> wrote in message
news:onp7g3ht4cukc8ght...@4ax.com...
Alex Kuznetsov
Bo,
I've got several years of experience doing such things. Based on my
experience, my advice is simple: don't do it, most likely you'll lose
a lot of money. There is a lot of gotchas involved. I described a few
of them here:
Bo Berglund
>
>Rereading your post, I guess I assumed some things.
>
>Is your application written in DotNet?
Nope,
we have developed the system since about 1996 using Borland Delphi and
initially with local Access databases. But from about 2001 we
converted everything to SQLServer when the customer installations grew
to many networked machines (PC:s).
Still using Delphi 7 though.
>
>// TransactSQL procedures to do most of the work in the database. Our
>>> applications in principle always use calls to stored procedures (via
>>> ADO) to enter and read data and to perform some calculations.
>>> There are *many* procedures!//
>
>
>ADO or ADO.Net?
We use the ADO interface to access the database.
>
>If you using ADO and VB6... than, man you're in for it.
ADO yes, VB6 no.
We switched to Delphi originally to get better speed and more easily
distributed applications (no masses of system DLL:s and OCX:es).
But also for the very good OO support in ObjectPascal.
>
>......
>
>If you've written a majority of your business logic inside the procedures of
>the database...than man... you're in for it.
We decided when we switched to SQLServer to put the business logic
*inside* the database in order to gain:
- Easier updates in a single place for a customer
- Quicker execution of database operations
- Possibility to encrypt the logic in the database
- Easier programming for the client apps, basically they just call
procs
What are the caveats of migrating TransactSql to whatever language
Oracle uses? I assume there is a possibility to store procedures in
the databas there too.
Bo Berglund
Tony Rogerson
ongoing support contract out of it, the likely cost in you migrating your
platform to Oracle would be substantial.
Even if you sold your app in there and sub-contracted the support out to
another company if you are not in the postition to support yourself.
Does your company really want the additional hassle and cost of keeping more
than one platform and subsequent releases per platform support costs -
imagine it.....
Tony.
--
Tony Rogerson, SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson
[Ramblings from the field from a SQL consultant]
http://sqlserverfaq.com
[UK SQL User Community]
Roy Harvey (SQL Server MVP)
wrote:
>But now we have this big potential customer who has an IT policy in
>place that all databases in the organization *must* be Oracle based...
I have no doubt that there is such a policy. However I have seen such
policies in action and in my experience the reality of what actually
happens in those companies can be quite different.
Roy Harvey
Beacon Falls, CT
Bo Berglund
<discu...@microsoft.newsgroups> wrote:
>Don't do it. You have no experience of Oracle. It won't work properly for
>the customer, they will not be happy. It will be a nightmare for you, you
>will not be happy. T-SQL and PL SQL are very different beasts once you get
>past basic selects and inserts so you will have to re-write ALL your stored
>procedures.
I fully agree!
Actually we installed our system way back in 1995 at this customer
using Access db. Then that system was upgraded a few years back to our
new SQLServer based system and the discussions at that time were also
towards Oracle. But we maintained that we did not want to do it just
for an upgrade and they could take our offer of upgrading to our
present system or leave it. However they had an even stronger IT
policy that all old NT3.51 and NT4 systems must be replaced with W2000
or XP-Pro systems and then finally they agreed on having us install
MSDE2000 as a dedicated server for that upgrade....
We argued in your lines then too.
>ADO will not work the way you want it to if at all so you will
>need a new strategy and code base for that.
So there is no ADO driver for Oracle then? Have to revert to ODBC?
>If this potential customer is
>all Oracle I would bet they are UNIX too which if you are a SQL Server shop
>you do not have experience of. Oh and you will need an Oracle DBA at $800
>dollars a day.
What is a DBA? A consultant?
>And unless the customer is stupid they will know this and
>know that the lower risk to themselves is to take your offering on the
>platform it was written for.
The actual users in the receiving department know this and do not
really want to go the conversion route, but the IT department up in
their clouds won't drop this issue...
>
>If on the other hand you want to break into the Oracle market go ahead and
>do a re-write of all your data access. Writing platform independent data
>access layers is not trivial but can be done. Remember though you will
>always have to maintain two code bases for your SPs, views and any other SQL
>scripts.
We don't want to go this route voluntarily, we are quite happy with
MSSQLServer, really! It's just that this customer is now looking for a
much larger new installation of our latest products into a different
department and it is hard to just say no off-hand. :-(
We have told them we will look into our costs for doing a conversion
if at all possible and give them a ballpark figure in 2 weeks.
The problem is not only the conversion itself of the database, also
all applications need to be worked over, I guess. And this will tax
our limited dev resources thus delaying other real developments, which
means less revenue from other activities.
And the future maintenance will also be a headache.
I guess we could quote them a fully qualified Oracle consultant for
two years plus our loss of other business to do the conversion....
Don't know if they will bite or (hopefully) give up and let us in with
an MSDE2000 again....
3000 consultant hours at $100 (very low, more probably $180) plus our
losses in other areas of say $300.000 would put the quote at
$600.000++....
>
>Nigel Ainscoe
>MBCS MCP
>
Thanks for discussing this with me!
Bo Berglund
Jim Underwood
> What are the caveats of migrating TransactSql to whatever language
> Oracle uses? I assume there is a possibility to store procedures in
> the databas there too.
>
differences the way you return a record set could not be more different.
You either need to explicitly code arrays on the client and server or deal
with reference cursors (think table variables, only requiring much more work
to define) which have to be passed as parameters. I dont think you can even
use the client code for the reference cursors.
Virtually none of your stored procedure code will port.
You will have to essentially write two seperate applications, one for Oracle
and one for SQL Server, and try to maintain them seperately.
Bo Berglund
<tonyro...@torver.net> wrote:
>Don't waste your effort - sell them a black box solution instead and get an
>ongoing support contract out of it, the likely cost in you migrating your
>platform to Oracle would be substantial.
>
>Even if you sold your app in there and sub-contracted the support out to
>another company if you are not in the postition to support yourself.
>
>Does your company really want the additional hassle and cost of keeping more
>than one platform and subsequent releases per platform support costs -
>imagine it.....
>
>Tony.
Definitely not! As I described in a different reply, we have sold to
this customer before (it is a multi-biilion-dollar corporation in
Sweden) and had to fight MSDE2000 in then too...
I am in development and not sales. And I'm not impressed by the
customer's IT dept arguments... Our sales guys are pretty interested
in this high profile customer though.
Bo Berglund
sloan
in this high profile customer though.//
I've heard that a thousand times.
"Do whatever it takes to get this customer signed".
Good luck dude.
If your company decides they're actually going to do this ( a rewrite in
Oracle ), I'd look for another job.
No matter how vested you are. It ain't worth it.
You gotta build an app from the ground up with the "These needs to work with
multiple RDBMS's".
I can't even begin to think about the number of man-hours and stress filled
nights your proposed project is going to supply.
"Bo Berglund" <bober...@home.se> wrote in message
news:je08g35hdi4uot1c1...@4ax.com...
sloan
We decided when we switched to SQLServer to put the business logic
*inside* the database in order to gain:
- Easier updates in a single place for a customer
- Quicker execution of database operations
- Possibility to encrypt the logic in the database
- Easier programming for the client apps, basically they just call
procs
//End Quote
I'm going to argue with you now, don't take it personal.
With those decisions, you've basically married yourself to Sql Server.
Which is fine if you choose to do that.
But now you don't want to be married to Sql Server. And you're in a big
corner. (Again, I've been there, so I'm not taking shots at you, just
letting you know what I feel is your situation).
But when others are saying "Don't do it", I think they mean about the same
thing. Its a huge hole to overcome.
//
- Quicker execution of database operations
//
I disagree. Too much business logic in your procedures may be faster for 1
person hitting the database. But when 1,000 or 2,000 people are hitting it,
you don't want super-duper figure out stuff running. You want the db to do
what a db is meant to do. Be an ATOM(ic) place for Data.
//Quote
What are the caveats of migrating TransactSql to whatever language
Oracle uses? I assume there is a possibility to store procedures in
the databas there too.
//End Quote
Oracle is NOT Sql Server. It a vastly different. I have above average TSQL
skills (I think??) and when I used Oracle for 8 months, I was like "I don't
know anything".
I would take a look at this article:
http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp
I don't say read it "as gospel", but read it to be introduced to the other
side of the coin.
If you ever build a new solution from the ground up in an OO language, then
re-read my first post.
My Advice:
Get your CEO to play golf with someone who uses Sql Server, and not Oracle.
I wouldn't go down the path you're thinking about, if it was me.
Good luck.
"Bo Berglund" <bober...@home.se> wrote in message
news:ulu7g357dvh3eh0n2...@4ax.com...
Bo Berglund
>//Our sales guys are pretty interested
>in this high profile customer though.//
>
>
>I've heard that a thousand times.
>
>"Do whatever it takes to get this customer signed".
>
>
>Good luck dude.
/:-D
>
>If your company decides they're actually going to do this ( a rewrite in
>Oracle ), I'd look for another job.
>No matter how vested you are. It ain't worth it.
>
>You gotta build an app from the ground up with the "These needs to work with
>multiple RDBMS's".
>
>I can't even begin to think about the number of man-hours and stress filled
>nights your proposed project is going to supply.
>
I'm glad I asked here and got the views from you all!
These will be used in our internal decision making and hopefully there
will be no port to Oracle at all....
Thanks again!
Bo Berglund
sloan
Another quirk I noticed (though its not really a violation of anything) is
that when a column is nullable, when you do an order by on that column,
Sql Server brings them back with the nulls first....then the populated
values. Oracle brings them back with the populated values, then the nulls.
(Or it might be vice versa).
I ~~think that's what it was, this was circa 2004 when I saw that little
quirk.
CREATE TABLE dbo.UserInfo (
UserUUID uniqueidentifier NOT NULL DEFAULT NEWID() ,
FirstName varchar(32) not null ,
LastName varchar(32) not null ,
MiddleName varchar(32) null ,
EmailAddress varchar(48) null ,
CONSTRAINT user_useruuid_key UNIQUE ( UserUUID ) ,
CONSTRAINT user_emailaddr_key UNIQUE ( EmailAddress )
)
GO
INSERT INTO dbo.UserInfo ( FirstName, LastName, MiddleName , EmailAddress )
values ( 'John' , 'Smith', 'JingerHeimer' , newid() )
INSERT INTO dbo.UserInfo ( FirstName, LastName, MiddleName , EmailAddress )
values ( 'Mary , NULL, 'DontKnowHerLastName' , newid() )
Select * from dbo.UserInfo ORDER BY MiddleName
If you code up that example in Oracle, I think you get the behavior above.
I think this was SqlServer2000 and Oracle 8i when I did it (???).
I don't have an Oracle/TOAD setup here to test.
"Alex Kuznetsov" <alk...@gmail.com> wrote in message
news:1191444235.1...@r29g2000hsg.googlegroups.com...
Erland Sommarskog
> So there is no ADO driver for Oracle then? Have to revert to ODBC?
There are OLE DB providers for Oracle. Microsoft's own MSDAORA is outdated,
but Oracle have their own.
>>If this potential customer is all Oracle I would bet they are UNIX too
>>which if you are a SQL Server shop you do not have experience of. Oh
>>and you will need an Oracle DBA at $800 dollars a day.
>
> What is a DBA? A consultant?
DBA = Database Administrator. They say that Oracle requires more
administration than SQL Server, but I'm an SQL Server guy so I don't know.
In a way you are asking in the wrong crowd, but maybe you have posted an
inquiry to an Oracle forum as well. People there are likely to me more
enthusiastic.
Moving your product to Oracle, probably means that you have to develop
a second product. Given that you have the business logic in the database -
which is the correct decision in my opinion - it will be impossible to
maintain a single code base. Also, given that you don't have any experience
of Oracle, you will have a learning curve.
So it is a high-risk project. But if you can get your customer to take
that risk and pay for the development, you will in the end have a wider
portfolio, and your own technical experience have improved.
So a good answer to your customer is: "it would take as long time to move
to Oracle, as it would to develop it from scratch". Reasonably, at some
point your customer will realise it's cheaper to keep you on SQL Server
with the extra hassle for the admin of a foriegn engine than to pay for
full-scale development.
--
Erland Sommarskog, SQL Server MVP, esq...@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Erland Sommarskog
> //
> - Quicker execution of database operations
> //
> I disagree. Too much business logic in your procedures may be faster
> for 1 person hitting the database. But when 1,000 or 2,000 people are
> hitting it, you don't want super-duper figure out stuff running. You
> want the db to do what a db is meant to do. Be an ATOM(ic) place for
> Data.
systems in my opinion. Say that you a million bank accounts, and you need
to compute the accrued interest at the end of the day. Do that client-side?
Get all the transactions for the accounts to the client, and then send
all the updates back when you are done? It's a lot of data to move over
the network. Particularly, if you get the idea to loop account for account.
raibeart
saying, they need a real SQL Server and not the toy
version. And, you should have moved everything to
SQL 2005 by now and got the performance increses
it would be giving you.
My answer would be, "We can migrate you to SQL Server
standard and handle all of your xyz needs simply by
upgrading to the paid version of the SQL software."
If they still insist on Oracle wish them luck.
Robert
On Oct 3, 3:50 pm, Bo Berglund <bobergl...@home.se> wrote:
> On Wed, 3 Oct 2007 21:19:26 +0100, "NigelA"
>
Jim Underwood
I think you are making an unfair comparison. There is a huge difference
between doing batch processing on the server, and embedding all of your end
user business logic in the database. There is application functionality
that is (ideally) supposed to happen between the GUI and the data, then
there is batch processing that does not involve a GUI, except perhaps to
schedule it.
"Erland Sommarskog" <esq...@sommarskog.se> wrote in message
news:Xns99BF627C8...@127.0.0.1...
Alex Kuznetsov
> sloan (sl...@ipass.net) writes:
> > //
> > - Quicker execution of database operations
> > //
> > I disagree. Too much business logic in your procedures may be faster
> > for 1 person hitting the database. But when 1,000 or 2,000 people are
> > hitting it, you don't want super-duper figure out stuff running. You
> > want the db to do what a db is meant to do. Be an ATOM(ic) place for
> > Data.
>
> Having the business logic in the database is almost a must for scalable
> systems in my opinion. Say that you a million bank accounts, and you need
> to compute the accrued interest at the end of the day. Do that client-side?
> Get all the transactions for the accounts to the client, and then send
> all the updates back when you are done? It's a lot of data to move over
> the network. Particularly, if you get the idea to loop account for account.
Hi Erland,
I think that it is better to implement some more complex business
logic on the client, just because T-SQL is not a powerful language. I
mean we try to compare both alternatives, and a well written C# or C++
module is often a clear winner, even with the overhead of moving data
over the network.
Bo Berglund
<esq...@sommarskog.se> wrote:
>Bo Berglund (bober...@home.se) writes:
>>>and you will need an Oracle DBA at $800 dollars a day.
>>
>> What is a DBA? A consultant?
>
>DBA = Database Administrator. They say that Oracle requires more
>administration than SQL Server, but I'm an SQL Server guy so I don't know.
So that is what it is...
We are all DB admins in tha case, I guess.
>In a way you are asking in the wrong crowd, but maybe you have posted an
>inquiry to an Oracle forum as well. People there are likely to me more
>enthusiastic.
The reason is that I found no Oracle newsgroup. The one at Gmane had
its last posting several years ago...
And I figured here would be some experience anyway, but
notwithstanding I put a discalimer about posting here in muy initial
post.
>Moving your product to Oracle, probably means that you have to develop
>a second product. Given that you have the business logic in the database -
>which is the correct decision in my opinion - it will be impossible to
>maintain a single code base. Also, given that you don't have any experience
>of Oracle, you will have a learning curve.
>
>So it is a high-risk project. But if you can get your customer to take
>that risk and pay for the development, you will in the end have a wider
>portfolio, and your own technical experience have improved.
>
>So a good answer to your customer is: "it would take as long time to move
>to Oracle, as it would to develop it from scratch". Reasonably, at some
>point your customer will realise it's cheaper to keep you on SQL Server
>with the extra hassle for the admin of a foriegn engine than to pay for
>full-scale development.
Today we made a count:
about 120 tables all with identity columns and a lot of foreign keys
and indexes.
Our procedure script contains about 30.000 lines of TransactSQL code.
Our other scripts (to build and update the database) are about 15.000
lines of code.
We have calls from TSQL to external DLL:s to handle licensing issues
(via dongles). These may also be a problem with Oracle.
All in all this has been built during 5 years and I don't think any
customer is crazy enough to pay for a duplication effort into Oracle
which does not bring any added advantages (keeping my fingers
crossed).
Bo Berglund
Bo Berglund
wrote:
>MSDE!!!!! Give me a break. If this is as "big" as you are
>saying, they need a real SQL Server and not the toy
>version. And, you should have moved everything to
>SQL 2005 by now and got the performance increses
>it would be giving you.
>
>My answer would be, "We can migrate you to SQL Server
>standard and handle all of your xyz needs simply by
>upgrading to the paid version of the SQL software."
>
>If they still insist on Oracle wish them luck.
>
You don't realize the scope of the system. We are not performance
blocked because we do not have a lot of concurrent calls or any large
amounts of data either. This is not a banking or administration
package, it is the data store and processing backbone of an industrial
automation system handling robots and machine tools etc in automated
fabrication.
In this scenario MSDE2000 is OK, but of course we do offer to install
into a full version of SQLServer if the customer happens to use that.
We started in SQLServer 7, then moved to 2000 and now can offer also
2005. but due to problems with our automated installers we do not
distribute the SQLExpress for those that do not have a full server.
Bo Berglund
sloan
with MSDE or Express.
Not all clients need super-duper editions.
Thank goodness MS gave us MSDE and Express.
Back in the day, your choice was Access or Sql Server 6.5/7.0 (full
versions).
Which was the choice between a 1977 Ford Pinto and a 1999 Mercedes.
At least MS gave us a 1989 Ford Taurus as an option.
............
"Bo Berglund" <bober...@home.se> wrote in message
news:nb6ag3tvaioadhpi9...@4ax.com...
Alex Kuznetsov
> I don't think there's anything wrong with giving it the ole' college try
> with MSDE or Express.
>
> Not all clients need super-duper editions.
>
> Thank goodness MS gave us MSDE and Express.
>
> Back in the day, your choice was Access or Sql Server 6.5/7.0 (full
> versions).
>
> Which was the choice between a 1977 Ford Pinto and a 1999 Mercedes.
>
> At least MS gave us a 1989 Ford Taurus as an option.
>
I'd rather have a civic or an accord
sloan
(OT)
I was with you until about 5 months ago.
My wife's civic's transmission died at <120,000.
Honda knows they were junk (transmissions), but won't do anything about it.
http://www.carcomplaints.com/Honda/Civic/2001/transmission/index.shtml
If you go to the homepage...the top 5 complaint (as of today) is this
transmission.
http://www.carcomplaints.com/
"Alex Kuznetsov" <alk...@gmail.com> wrote in message
news:1191523777....@22g2000hsm.googlegroups.com...
Erland Sommarskog
> The reason is that I found no Oracle newsgroup.
I have the impression that comp.databases.oracle is a lively place.