October 3, 2008 at 9:20 am
I have copied x number of rows from Table A on Database1 TO Table B on database 2 (both are on the same server/sql 2005) AND I am able to see all the copied data in Table B.
But the problem is that the front end application lists data related to single id and does not list the entire data..
Help on this is really appreciated!!!!
October 3, 2008 at 9:33 am
This isn't a data coruption problem - this is an issue with your application logic or table schema...
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
October 3, 2008 at 9:38 am
Sounds like you have some relational data issues, not corruption as Paul stated. How did you go about copying and what method did you use in order to ensure that your referential integrity was going to be maintained?
More detail will be helpful...
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
October 3, 2008 at 9:39 am
Sorry for posting in the wrong thread!!! We are using a client server application (citrix). Also, the destination database is the copy of original database. Will there be a difference in schemas?
I have the exact number of rows in destination db as in source db. But only rows related to 1 foreign key r being displayed?
October 3, 2008 at 9:44 am
Hey David!!!
I used to a job with Insert into query...As i said the destination table is a copy of source table? Will there be a referential integrity issue for this? correct me if i'm wrong? I'm new to sql server 2005.
October 3, 2008 at 10:02 am
My immediate question is whether those tables have an identity column on them and if so, did you do an insert with the original identity value in the previous table or did you let it build new identity information? Let me know if you need me to clarify this question.
Side note question but if this is a identical to the original could you have done a backup / restore to the new location for your application?
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
October 3, 2008 at 10:10 am
There is no identical column. I have inserted rows related to three id's 3,13, and 14 and they all (2200 rows) show up in the destination database. But when i log in to the front end application it lists items related to id 3 only. Rows related to 13 and 14 are not coming up.
Thanks
Mahesh
October 3, 2008 at 10:34 am
Being that this is only one table I might have assumed something incorrectly. However, you mention that there are id's 3, 13, and 14. What do they relate to and how does the application table use them? Is there another table that the application uses in order to relate those id's to something meaningful in the application that will need to be copied over as well?
That is the only thing that I can think of. Hopefully this makes sense.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
October 3, 2008 at 10:40 am
Hey David,
All these ID's relate to a column called 'Price List Id' . My concern is if one id (3) is showing up in the front end, why not the remaining two?
October 3, 2008 at 10:48 am
Just a guess but there might be a "PriceList" table that would then contain more information that those ID's would relate to which the application would then build it's select statments from. So, you might want to look for that table and ensure that it is populated identically to the other database as well. Most times it is not only one table that needs to be copied.
Ultimately anytime you try to recreate application data in another environment there are almost always inherent links associated to the data in a table (specifically on those columns that are called ID or something similiar). These types of tables are commonly referred to as Lookup tables or something similar.
Since that is often the case, it is almost always better to run a backup / restore to the "test" environment and then alter data as necessary to make sure that you are not doing bad things with real customer data (i.e. alter email addresses to internal emails so you don't send out bad emails from a test box, change billing information, etc)
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
October 3, 2008 at 10:53 am
Thanks David!!! I will look in to it and get back to you.
October 3, 2008 at 10:56 am
Hope you find it as I am just about out of ideas.... 😛
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
October 3, 2008 at 11:01 am
Hey David,
I found the solution..as you said, it is related to the lookup tables. Thanks a bunch for your help!!!
October 3, 2008 at 11:09 am
Woo Hoo! Huge sigh of relief on my end as well. Glad to be of help.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply