DataMember property <<Relationship_Reference>> cannot be found on the DataSource
Hello Experts.
It's been a while since I've last posted a question. I had pretty much given up on my VB.NET Windows Form project, but something stirred up inside me, and I'm back on the horse.
Somewhere in the process of making code changes and fixing bugs, I got it in my head that I wanted to change the back-end database structure. This included changing the key to a data table called "Teams" from being Int32 to String. I also needed to change some other tables which reference the Teams key, but strangely that didn't include the ones in the error I'm trying to resolve. I'll admit it right now, my biggest mistake is that I use MS Access to make the changes. Of course now, I'm needing someone to throw me a rope, and help get me out of deep water so I can go back to coding.
I'm pretty sure that changing the table's key datatype was not the problem "per se" but because Access requires you to remove the relationships before making that kind of change. Yes, I put back the relationships, but now whenever I try to fire up the Designer, I get these errors:
I've been going through my project trying to repair the damage on my own, but so far have not gotten much success.
Any suggestions on a good place to start would be very much appreciated!
Here are some of the relevant project files, let me know if there are others you need to review:
frmSnapMain.Designer---Copy.vb.TXTfrmSnapMain---Copy.resx.TXTSNAPDataSet.Designer---Copy.vb.TXT
It's been a while since I've last posted a question. I had pretty much given up on my VB.NET Windows Form project, but something stirred up inside me, and I'm back on the horse.
Somewhere in the process of making code changes and fixing bugs, I got it in my head that I wanted to change the back-end database structure. This included changing the key to a data table called "Teams" from being Int32 to String. I also needed to change some other tables which reference the Teams key, but strangely that didn't include the ones in the error I'm trying to resolve. I'll admit it right now, my biggest mistake is that I use MS Access to make the changes. Of course now, I'm needing someone to throw me a rope, and help get me out of deep water so I can go back to coding.
I'm pretty sure that changing the table's key datatype was not the problem "per se" but because Access requires you to remove the relationships before making that kind of change. Yes, I put back the relationships, but now whenever I try to fire up the Designer, I get these errors:
- DataMember property "TableTypesLocations" cannot be found on the DataSource.
- DataMember property "TeamsRoster" cannot be found on the DataSource.
- DataMember property "TeamsRoster1" cannot be found on the DataSource.
I've been going through my project trying to repair the damage on my own, but so far have not gotten much success.
Any suggestions on a good place to start would be very much appreciated!
Here are some of the relevant project files, let me know if there are others you need to review:
frmSnapMain.Designer---Copy.vb.TXTfrmSnapMain---Copy.resx.TXTSNAPDataSet.Designer---Copy.vb.TXT
PatHartman
I would go back to the backup of the BE and start again. This time, turn off the Name Autocorrect feature. It may have been what caused the problem.
ASKER
Thanks so much for jumping in, Pat. Unfortunately, it would appear that I have since overwritten that particular backup with the aforementioned modifications. Worse, my Restore Previous Files feature is disabled. That being said, if there are any other suggestions, I would be very much appreciative!
Tony
Tony
I guess a good start is to go to the Dataset Designer and check if the messages are actually pointing to your issue...for example do you have a TableTypesLocations table ?...can you preview its data...
From a quick glance at your Dataset code there are 13 mentions of the TableTypesLocations as part of relations/rows ...etc but there is actually no table definition by the name TableTypesLocations...some
From a quick glance at your Dataset code there are 13 mentions of the TableTypesLocations as part of relations/rows ...etc but there is actually no table definition by the name TableTypesLocations...some
Private TableTypesLocations As LocationsTypesDataTableASKER
Thanks for the insights John. We may be onto something here. So, we know that a relationship is not an actual table, but rather a way to "drill down" from a given table (the parent), say "Locations" for example INTO another table (the child), in this case "TableTypes". As you can see in the image I added, the Locations table contains a field of "TableType_ID" and this is the key to the TableTypes table (TableType_Key).
So when I looked at the relationships on my Dataset Designer, everything looked just fine. BUT if I go to my Data Sources table (shown on the right of the attached image), I noticed that the Parent/Child relationship was backwards causing TableTypes to have a sub-table (relationship) of Locations -- totally useless.
So I removed the relationship, and recreated it with the correct Parent/Child relationship, and now I am down to two remaining errors when attempting to bring up the Designer: TeamsRoster and TeamsRoster1.
I will continue working on making sure that all Parent/Child relationships are set correctly, and report back tomorrow if we're "out of the woods".
Thanks Again!
Tony
So when I looked at the relationships on my Dataset Designer, everything looked just fine. BUT if I go to my Data Sources table (shown on the right of the attached image), I noticed that the Parent/Child relationship was backwards causing TableTypes to have a sub-table (relationship) of Locations -- totally useless.
So I removed the relationship, and recreated it with the correct Parent/Child relationship, and now I am down to two remaining errors when attempting to bring up the Designer: TeamsRoster and TeamsRoster1.
I will continue working on making sure that all Parent/Child relationships are set correctly, and report back tomorrow if we're "out of the woods".
Thanks Again!
Tony
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks so much for the sage advice gentleman. With a lot of blood, sweat and fears tossed to the wind, I was able to finally get my Designer to come back up.
As I recall, there were four errors which all appeared to be similar, but each one required a different solution. The last two were by far the most challenging, since I had to compare and contrast each and every Binding Source to reveal either the missing component, or extrapolate what needed to be re-keyed.
On one hand, I hope I don't need to post anything like this again, but life has taught me many lessons, most of which I'll need to re-learn again, but at least I know that I'm in good hands with Experts Exchange!
All The Best,
Tony Gardner
As I recall, there were four errors which all appeared to be similar, but each one required a different solution. The last two were by far the most challenging, since I had to compare and contrast each and every Binding Source to reveal either the missing component, or extrapolate what needed to be re-keyed.
On one hand, I hope I don't need to post anything like this again, but life has taught me many lessons, most of which I'll need to re-learn again, but at least I know that I'm in good hands with Experts Exchange!
All The Best,
Tony Gardner
Glad you got this worked out. Sounds like you had to make the VS diagram match the Jet/ACE diagram. I'm not sure how these two products work together. I only know how Access works when dealing with ODBC. I can use DAO or ADO code or DDL to manipulate a schema in a non jet/ACE RDBMS but normally I would go to the native GUI such as SSMS for SQL Server and make the change there because that would allow me to use graphical tools. Then i would go back to Access and refresh the links so I could see the changes.
Some unsolicited advice - If you are going to encumber yourself with Jet/ACE as your database engine, you might consider taking advantage of the RAD tools provided by Access to build the app and reduce your overall workload. All the bad press "Access" gets, isn't actually directed at Access the RAD tool, it is directed at Jet and ACE by people who do not know enough about either product to distinguish them from each other. Access is not welded to Jet/ACE as a data store. Access can use ANY RDBMS that supports ODBC so the limits and constraints everyone complains about are completely irrelevant because they apply to Jet/ACE and if your Access FE is not using Jet/ACE to hold its data, then it is infinitely scaleable. The number of concurrent users and limits to database size are under control of the RDBMS and are not affected by Access. All you have to do is to understand how Access handles client/server and ensure that each user has his own personal copy of the FE to avoid conflicts with other users.
Some unsolicited advice - If you are going to encumber yourself with Jet/ACE as your database engine, you might consider taking advantage of the RAD tools provided by Access to build the app and reduce your overall workload. All the bad press "Access" gets, isn't actually directed at Access the RAD tool, it is directed at Jet and ACE by people who do not know enough about either product to distinguish them from each other. Access is not welded to Jet/ACE as a data store. Access can use ANY RDBMS that supports ODBC so the limits and constraints everyone complains about are completely irrelevant because they apply to Jet/ACE and if your Access FE is not using Jet/ACE to hold its data, then it is infinitely scaleable. The number of concurrent users and limits to database size are under control of the RDBMS and are not affected by Access. All you have to do is to understand how Access handles client/server and ensure that each user has his own personal copy of the FE to avoid conflicts with other users.