Can somebody Explain!!!

C

cmaras

Member
Joined
Jul 1, 2003
Messages
13
Hello,

I have read a lot of the theards and post regarding the subject of inserting, updateing and deleteing rows in a database using the OleDb.OleDbDataAdapter.

If somebody could give me a good explanations how the the
OleDb.DataAdapter.InsertCommand
OleDb.DataAdapter.UpdateCommand
OleDb.DataAdapter.DeleteCommand
OleDb.DataAdapter.SelectCommand

work I would be most greatful.

Problems Im having today is that I dont really know how they work together. As they have to be set seperatly but I guess they are all bound to the same DataAdapter?

Also if I create a Public decleard DataAdapter and call on it to perform different operation is this the correct way of doing this. Or should I declear the DataAdapter is each Sub?

What information is needed for each command and how you create them. I do NOT want to use the command builder I want to know how to set these 4 properties myself.

Any feedback is appriciated, I am very green so please be patient.

Thank You,
Claudio
 
I would *first* use the CommandBuilder. It will set all of the above properties for you. You can then view them (Debug.WriteLine, use the Locals, Autos, or Watch windows, etc.) to see what they look like.

I would recommend setting them once (not in a sub, but in a constructor or similar place). They work with a DataSets changes, of course. So to see it work youll have to have a DataSet with at least one row modified, added, or deleted. The DataAdapter will call the proper command for each row.

Now, if you have MANY inserts, updates or deletes, you may not want to use the DataAdapter. If you have 10 or 20 I wouldnt worry, but if you get many more than that you may want to rethink your code as you will want to either limit the amount of changes at one time or pass XML up to the database to be worked on in one chunk (only available in SQL Server).

-Nerseus
 
Thank you for your response, I dont know how to use the Debug.WriteLine, but I do know how to do the basics with the Autos and Locals even though lots is missing to do proper debugging.

I did find what my problem was, it had to do with the autonumber generated by the Access DB. Solution was that I built a very simple table without autonumber and used the insertcommand and it worked no problem and then added on the complexity of Primary Key and autonumber and ran into the problem again where I finally indentified the problem

Also the objNewRow had a setting for the autonumber column that wasnt helping either.

Leason learnt is, START OUT SMALL... :)

Thank you for your help, I would still want a leason in how to more efficiently debug my code. If you feel up for a quick lesson Ill be here listening. Remember Im very green so the obvious is a mystery ;)

Thnx,
Claudio
 
Well to use Debug.Write or Debug.WriteLine, simply add a using (or Imports in VB) statement at the top of the class for the library "System.Diagnostics". Or, you can use System.Diagnostics.Debug.WriteLine() (I prefer the using/Imports line). It writes out to the Output window by default. If you dont have one open, press Ctrl-Alt-O. It should come up every time you run as it shows the build process, warnings and errors, etc.

It has limited usefulness as you have to recompile to add a new Debug.WriteLine statement. But, if you want to put one in every event you can trace the order of events and such.

The autos/locals windows are immensely helpful as you can drill down to see any property of any object (more or less). Not much to explain there - if you think variable a has a value, expand the treeview window and look at the property to see the value.

Theres a CallStack window, too. If you set a breakpoint in a function or event, you can open the CallStack and see everything thats executed up to that point. Double clicking takes you back to the code that called it. Bold items are YOUR code, grey lines are system DLLs or other code thats unavailable in source mode.

If you use breakpoints to stop your code and look at the state of things (always a good idea), then you should be aware that you cant walk into an event. Meaning you can normally press F11 and step INTO a function (or F10 to step over it). If youre on a line of code such as "this.Show()" or "Me.Show()" and you know the next event is Form_Load, it will not step into Form_Load (an event). Youll have to set a breakpoing in Form_Load to continue walking through the code there.

If you have any specific debugging questions, such as how to do a certain something, let me know :)

-Nerseus

PS I forgot to mention that breakpoints can now be conditional. Meaning, you can right-click a breakpoint and select properties. You can then have the breakpoint only trigger on the 2nd time it hits, every other time it hits, etc. Very neat-o stuff. Not to mention, breakpoints and their properties are now saved with your project :)
 
Thank You,

lots of interesting info, one thing I did not understand was the stepping into and out of functions or subs.

As that works just fine with F8 for me, if I have a sub that calls a function or another sub in a module by pressing F8 I jump through the code line by line. Of course I have to set a breakpoint first and then I use F8 from there.

When it hits a line that calls another function/sub it jumps to that code and I execute it line by line with F8 until the function/sub is complete and then it jumps back inte the original sub/event.

The whole F11 I never understood, I have to use F8 to step through code after a Breakpoint is set.

I liked what you said about the properties of brakepoints, I can imagine that helping when you have a Loop going on. I once stepped through a loop that vent for 250 times just to verify the end...LOL

Thanx again,
Claudio
 
Ah, you must have chosen VB6 compatability when you setup Visual Studio. The F10 key corresponds to F8: step into. Step Into means pressing the button on a call to a function will next walkthrough code inside of the function. If you press Shift-F8 (or F11) - youll step Over a function. Meaning the code inside the function runs (and will still stop on a breakpoint if one is set), but you wont stop on any lines inside the function.

If Im running through a loop 250 times, I dont usually put a breakpoint with a count of 250. I just set a breakpoint on the line after the loop - unless of course you want to walk through the loop but only on the 250th pass. :)

-Nerseus
 
Back
Top