Exporting and Importing between Repositories PROBLEM

[srjosyula]

Hi
I have a problem in exporting and importing the Objects between repositories in Informatica.

Problem:

I had first exported the mappings as objects from our QA server.

Then I had to import them onto our Production server, when I tried to do that, during the import, I was also importing the QA sources along with the mapping.

So now even after importing the whole thing into production, the mapping was still using sources from QA.

I deleted the QA sources from the repository, and re – connected the mapping with production sources (which I had got from the source analyzer).

Is there a way to get around this problem?

Thanks in advance!

 

[blom0344]

Designer objects only relate to structure. The actual connection is configured in the related session.
In most cases it pays of (if you are not yet working with version 7/8 + version control) to make folder copies.

However, if you have different connections between repositories you will still need to adjust connections

Ties Blom

 

[srjosyula]

Will try thank you Ties.

 

[srjosyula]

Usually does everybody use the Productions sources in all the environments?
I mean if i am in the QA repository, should I still be using the production service name when importing the sources from the source analyzer, so as to get the sources from production?
In this process when I export the mapping to production, it would still be pointing to the production environment right?
I am asking so because, when I export if i go to advanced options and click off "export non reusable transformation...." I get an import error when I use that object.
Please advice

 

[ArtieChoke]

Usually does everybody use the Productions sources in all the environments? I mean if i am in the QA repository, should I still be using the production service name when importing the sources from the source analyzer, so as to get the sources from production?

It doesn't really matter where they come from, but they should have the same name and schema definition as what's in production. Then you won't have any issues when migrating from deveopment/test to production. Also, if you are modifying your tables in test, then you want to import from the test database and promote those once you go live. If you are not testing on exact copies (schema-wise) of the production database, then you're asking for problems.

In this process when I export the mapping to production, it would still be pointing to the production environment right?

In terms of sources, if they match in both databases, you won't have to change anything. The production enviroment should be defined by the connections only, not the sources. If you have the same connections in both repositories, then your maps will inherit the production connections, which should point to the production databases. In test, you point the connections to the test databases, but leave the connect names the same as in production.

I am asking so because, when I export if i go to advanced options and click off "export non reusable transformation...." I get an import error when I use that object.

And you should get errors, since you're missing transformations in your maps. Unless you explicitly specify a transformation to be shareable (reusable), it will default to private. You still want to copy those over.

What version are you using? If it's 7 or higher, you should really use deployment groups.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[srjosyula]

Thanks a lot Artie,
I am using 7.1.3 right now. I am really ignorant of the deployment groups.
We have 3 repositories
DEV
QA
PROD
My primary problem was that, when working in the QA repository I had created an ODBC Connection to get the source tables. In doing so, I gave a Data Source name say "****QA" and its respective service name.

Now when I export the mapping and import the same into Production, where in I have a different service name for the production sources, the import wizard, is importing the sources from QA into production.
thank you

 

[blom0344]

You need to distinguish between the local connection that you use to import the sources and the consequent action that you may or may not start by renaming them.
Do not mess with the source names if you need to reuse them in another environment.

Version 7 allows you to work with team-based development, version control and using native deployment between environments. (As opposed to hardcopying objects)

Ties Blom

 

[ArtieChoke]

What I do is use the same DSN name, no matter which database it points to and have the name be generic so when the sources are imported, they always go to the proper area.

For example, we have production, test and development data warehouses, so I've named my DSN "Warehouse" and all sources for those databases go into that area. If I need to import from test, then I change the database in the DSN.

The other way around it is to modify the database name in the source, but that can get you in trouble too if you have an existing one that you want to replace and have versioning turned on. You have to delete the original and check it in before you can do the rename. That's pretty lame if you ask me!

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[srjosyula]

thanks folks shall try!