Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2003-06-19 : 07:30:09
|
| Paul writes "I have a client with a variety of applications using a variety of databases that we would like to "port" to SQLServer. Actually we don't want to port the app, we want a shim that will make the existing app think it's talking to its database but will actually be talking to SQLServer. All this in hopes of eventually consolidating 5 distinct customer data stores into one. So, any suggestions? We're starting with ProsystemFx which uses the Advantage database." |
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2003-06-19 : 10:21:03
|
| Very interesting ...Provide more background if you could. What platforms are you running on currently? What are the 5 distinct data stores? (Oracle, DB2, etc)Also, I've been in this industry for a while and have never heard of ProsystemFx or the Advantage database.Jonathan{0} |
 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-06-19 : 18:56:23
|
While I agree it sounds like an interesting project, I have never seen or had an experience where:quote:
Actually we don't want to port the app, we want a shim that will make the existing app think it's talking to its database but will actually be talking to SQLServer.
...didn't turn out to be a horrific nightmare, bad enough to make one reconsider their career in IT. I'm serious. If you're going to port anything, you're better off doing it from the ground up and ignoring the existing app. If the current app logic can't be changed, you'll gain no benefit from trying to trick it into using SQL Server. If it is even possible, and even if there's a performance improvement, the effort and heartache and problems you'll encounter will not be worth it. The only chance you have is if the app has a data access layer that is completely separate from the rest of it. Considering that I too have never heard of either system you mention, it's unlikely they follow this kind of accepted standard that you can use to bridge them to SQL Server. |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2003-06-19 : 19:26:43
|
| I totally 100% agree with Rob. I think these are some of the questions that need to be answered before you move forward:1. What do you hope to gain by moving these apps to SQL Server?2. How much time and resources are required to make this "sql hack" work for you?3. How much time would a re-write take?Management never seems to like re-writes. They always like quick fixes. Quick fixes turn out to require more quick fixes. This continues until you have a system so complicated that noone can manage it. It's at this point when a re-write is given serious consideration. Why not skip all the bad stuff and go right to the best solution, which is a re-write. If you do this, you can take advantage of SQL server (and other technologies) and see some real performance and maintainability gains vs the "port" you are proposing.I'm not trying to slam you or your ideas Paul. In fact, I've been in your shoes more than a few times. I think many of us here have been. I'm just trying to tell you like Rob has told you that you are in for a world of frustration. You'll need to find a way to get data out of your existing databases and into SQL Server. Then (and this will be the tough part) you'll have to find some way to make your current apps talk to SQL server instead of their native databases. If they use ODBC, it will be easy. If not, it's gonna be hella tough methinks. I really don't think any human on this planet could get this done man. Sorry :(Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
|
|
|
|
|
Porting/Views