tableadapter insert not working

.net Noob

Member
Joined
Nov 28, 2011
Messages
14
Programming Experience
10+
I have a combobox on my form that I want to populate from a datatable. I have set up a table, and a dataset and a table adapter. To load the table with data (about 50 records) I put the data in an array and looped through it, calling the tableadapter's insert method each time. However, it is not inserting anything into the table.

Here is my code:

Dim genray() As String = {"Action and Adventure", "Chick Lit", "Children's", "Commercial Fiction", "Contemporary", "Crime", "Erotica", "Family", "Fantasy", "Dark Fantasy", "General Fiction", "Graphic Novel", "Historical Fiction", "Horror", "Humour", "Literary Fiction", "Military and Espionage", "Multicultural", "Mystery", "Offbeat or Quirky", "Picture Book", "Religious and Inspirational", "Romance", "Science Fiction", "Short Story Collections", "Thrillers and Suspense", "Western", "Women's Fiction", "Young Adult", "Art & Photography", "Biography & Memoirs", "Business & Finance", "Celebrity & Pop Culture", "Music, Film & Entertainment", "Cookbooks", "Cultural/Social Issues", "Current Affairs & Politics", "Food & Lifestyle", "Gardening", "Gay & Lesbian", "General Non-Fiction", "History & Military ", "Home Decorating & Design", "How To", "Humour & Gift Books", "Journalism", "Juvenile", "Health & Fitness", "Multicultural", "Narrative", "Nature & Ecology", "Parenting", "Pets", "Psychology", "Reference", "Relationship & Dating", "Religion & Spirituality", "Science & Technology", "Self Help", "Sports", "Travel", "True Adventure & True Crime"}
For x = 0 To genray.Length
Me.GenreListTableAdapter.Insert(genray(x))
Next


I got the basic example right from MSDN.

What is wrong?
 
So it's giving an error message, right? saying "it's not working" isn't the most helpful description for folk to go on here!

Is your tableadapter insert method expecting a single string? Have you tested your method(s) manually?
 
I apologize. I'm not the greatest at describing things. No error. It just isn't inserting records. The table has two fields. An ID field that is auto incrementing, and a varchar field. I didn't think I had to reference the ID field since it auto increments.

I debugged and traced through the loop, and it went through every item in the array. I don't know why it isn't inserting records.
 
You're right in thinking you'd not need to supply the ID field.

Try popping a Try...Catch block around your tableadapter insert call to see if you can trap the error.

How was the tableadapter created? Through the designer, or code?
 
Through the designer. I used the Try-Catch. It was going all the way through the array, but I got an exception because I went one past the length of the array. Will that cause the database to not update? I thought it updated every time an insert statement was executed?
 
OK, no error now, but when I went to preview the data in the table, I got the error 'The path is not of a legal form'. I quit the designer, started it back up, and I can view the data, but there is still nothing there.
 
Last edited:
I don't think that's the problem. From what I can understand of what I read, I did say 'yes' when I got that message, and my dataset is set to copy always. It should be working.
 
I will take it back. I have 4 different copies of the database on my hard drive. I don't know how or why. I looked at each one and found where the data was going, but I don't know how to straighten out the mess from the designer without starting over. The data is going to the copy in Debug, but I want it to go to the copy that I designated in the root project folder. I know now that when I test in debug, the data will go there, but how do I get it to go both places? Or can I test my project without using debug?
 
Last edited:
starting over won't straighten it out

Answering Yes is the first "mistake" - it causes a copy of whatever DB you chose to be put in your project folder
This becomes the "clean" version of the db
Had you said NO, the db would have stayed where it was and all edits would have happened to it directly. This would probably have caused other complications further down the line

You have 4 copies because:
you have one in the root of c: (or wherever you regard your "original db" as being)
you have one in your project folder because you answered YES (i want to copy this db into my project)
you have one in your DEBUG folder because Visual studio copied the project one to DEBUG then the program runs editing the one in DEBUG
You have one in your release folder, for a similar reason to above except the compile mode was set to RELEASE in visual studio, at some point in the past


Given that VS copies the db from the prjkect folder into debug upon every run onf the program, it should thus strike you that all you have to do, if you want the db that is in debug folder (i.e. the one with data) to be copied out every time, you simply have to copy the db from debug back over the top of the db in the project folder

You can never get VS to edit the db that is in the project folder.. and indeed why would you want it to? That db is supposed to be your clean version, free of any test data and ready for release.. in the same way you wouldnt expect the paint program you're writing to edit all the icons for its own buttons in the project folder before you release the app.. cos then you'd have a messed up looking app

It does strike me that youdidnt really truly read the DNU link and think about what was going on.. Could I suggest that you read it again, more slowly this time?
 
OK, first, thanks for your help. I am sure I'll be able to figure it out from this last post.

Second, I read the DNU link 5 times. Slowly. If you noticed, my user name is .net Noob. I have never used .net, and even when I used VB6 I never used bound fields and data adapters and all that. That said, the DNU was...confusing. Sorry, but that's how it is. I know nothing about release versions and debug versions. Those did not exist in VB6 (I don't think). Please don't treat me like I should know what I'm doing. If I knew what I was doing I wouldn't be posting to this forum.


Oh, and now that I understand what's happening, starting over WILL straighten it out.
 
I'd welcome any feedback you had about the DNU link.. "it was confusing" doesnt really help me target a specific section to improve though; at what part did you start to lose understanding of what was going on?

It's less about debug and release, and more about the process that Visual Studio undertakes of copying all the necessary resources from the project folder, into the output folder, when VS compiles your app.. VS builds your code into YourApp.exe and puts it in bin\Debug, bin\Release or whatever build mode you have selected/created. it then copies out all the supporting stuff, and that's what your app uses
 
OK, reading it again now it isn't as confusing. I guess it was just thatI was trying to wrap my head around everything at once and I was confusing myself.

So what do I need to do to point my app to the right copy of the database? What would you do in my situation? I have no problem deleting all copies of the database and rebuilding it. I only have a dozen lines of code so far that would be affected. It's not a big deal. I'm chalking it up to learning experience.
 
I'd actually do this:
Have my db
Make a project
Add Existing Item.. Choose the db
Say yes to the "do you want to copy it in?"
Set the copy mode to "copy if newer"
Use Access (or visual studio's server explorer) to edit the copy of the db in the project directory, add in any default data I want in the app when first installed on a user machine, stuff like lookup tables data, default settings, etc
Then just run things normally, debug my app, add data, save it, view it

Copy If Newer ensures my changes by my debugging app remain (because the temporary working copy of the db is not replaced) unless I edit the project db's contents or schema (in which case we WANT it to be copied out again) but when I come to publish the app, my users dont see all the crap i put in there when debugging

This isn't a "problem", it's just that the default way VS manages its files (which is a good way) doesnt match your expectation (which probably isnt the best expectation tbh- your way of expecting the db will accumulate changes forever means you could end up distributing megabytes of crap to your users)
 
Back
Top