[EOgre0152]

I am having a problem, and am noth sure on which side of the fence it is on. Here's what I am trying to do:

I have a simple MS Access database with 2 tables that contain file names, numbers, file extenstions, etc. This is used to manage a list of files to be moved, deleted, archived, and programs to be activated.

I also have a Visual Basic 2005 program to do these tasks, and one portion of it is to be able to update the database rows (each row is a seperate "task"). To do this, I set up the data source via the wizard, then dragged onto the form bound text boxes and checkboxes. This automatically created a bar with a save, new, remove buttons on it, and created code behind to manage these functions. It also created a dataset and loaded the database information into it via the data adapter.

The problem is, I can make all the changes I want and "save them" and I get no exceptions or errors, but the database remains unaltered. The code that was generated is this:

 
	Private Sub SourceToDatabaseBindingNavigatorSaveItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles SourceToDatabaseBindingNavigatorSaveItem.Click
		Me.Validate()
		Me.SourceToDatabaseBindingSource.EndEdit()
		Me.SourceToDatabaseTableAdapter.Update(Me.ScheduleDataSet.SourceToDatabase)
	End Sub

	Private Sub grid_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
		'TODO: This line of code loads data into the 'ScheduleDataSet.SourceToDatabase' table. You can move, or
		  'remove it, as needed.
		Me.SourceToDatabaseTableAdapter.Fill(Me.ScheduleDataSet.SourceToDatabase)

	End Sub
End Class

Can anyone help here?

[tody4me]

if this is updating a view in access, access does not know how to update it. you have to create update commands for each table that is in the view, if using access. best way to test to see what is happening is to take and go into the SQL statement viewer for the database and type the command text of the update command and execute it there. exceptions are only thrown on serious errors, so if this is SQL and you are getting a warning, an exception will not be thrown. Need more information to help further.

[EOgre0152]

tody4me, on 27 Apr, 2007 - 09:04 AM, said:

if this is updating a view in access, access does not know how to update it. you have to create update commands for each table that is in the view, if using access. best way to test to see what is happening is to take and go into the SQL statement viewer for the database and type the command text of the update command and execute it there. exceptions are only thrown on serious errors, so if this is SQL and you are getting a warning, an exception will not be thrown. Need more information to help further.

The access database doesn't have any views in it, its not much more than two simple tables. The data source in my VB program is linking directly to the table, so the SourceToDatabaseTableAdapter is linked directly to the table I am working with (called SourceToDatabase). According to the book I have on VB 2005, this technique should go off without a hitch. The only difference between my situation and the book's example is the database that is used. No version restrictions were mentioned in the book, so I assume then that just about any version of access should function.

[Jayman]

Difficult to say, exactly what could be the problem here. There are times when the code-behind can get a little messed up. Especially if you add controls, deleted them and then add them back. The code-behind doesn't always do a very good job of cleaning itself up. Not to say that is your problem here.

If your project is not too big.
Can you zip up your project with the database and upload to this topic?

We will better be able to help you.

[EOgre0152]

jayman9, on 1 May, 2007 - 09:56 AM, said:

Difficult to say, exactly what could be the problem here. There are times when the code-behind can get a little messed up. Especially if you add controls, deleted them and then add them back. The code-behind doesn't always do a very good job of cleaning itself up. Not to say that is your problem here.

If your project is not too big.
Can you zip up your project with the database and upload to this topic?

We will better be able to help you.

Yeah sure can. It is small enough I think. The place I noticed the problem is in the sourcetodatabase.frm and sourcetodatabase2.frm This is a work in progress and was originally a VB6 program - I believe it was FIRST written in VB4. I have finished (I believe) the upgrade process from the old recordset mothods to datarow methods.

Attached File(s)

•  Project1.zip (828.34K)
  Number of downloads: 97

[Jayman]

It seems the biggest problem is the references, I am getting 22 warnings that there are problems. Looks like during the Upgrade conversion, all the DLL references have been renamed. An example from your project showing the new name, AXMSDBGrid has been changed to AXInterop.MSDBGrid and another MSDBGrid has been renamed to Interop.MSDBGrid

You can see in the attachment where I started replacing some of them and you can see the remainder that still have warning symbol on them.

I would suggest start by repairing those, then see where it gets you.

The problem with converting is it never works completely right. You will always need to go in and fix all the stuff that didn't convert properly. As I'm sure you already discovered.

Also, when I opened the database to check its structure I got an error stating something along the lines of a broken or missing file. I could not get the error to repeat when I opened the second time. So I could not get a screen shot for you.

But you might try recreating the database and then importing the data from the existing database into the recreated one.

By fixing the reference I'm able to get to the data, but with that error in the database. I think this may be why it will not perform any updates.

Attached image(s)

• 

[EOgre0152]

OK, thanks for the help btw. I replaced all references with their Interop equivilents and created a new database, importing information over to the new one. The odd thing is, I didn't have those warnings you were mentioning. I wonder why they would show up as warnings for you but not on my end. Nonetheless, the changes made did not affect how the program acts. I can still see data, and it appears to edit (VB side), but upon a second run of the program, no changes took effect.

[Jayman]

Are you sure you are looking at the right database?

It is updating the database that is located in the bin folder.

Here are some screen shots as proof.

Here is the program prior to making any changes.


Here it is after I change the first 4 lines have been modified.


Now here is the Table inside the database that was changed. This is the database that was located inside the bin folder.


So everything is working just fine in that respect. The real problem is that every time you run the program, it is copying the database that is located inside upper level folder of your project and overwriting the database that is located in the bin folder.

You can check this by renaming the database in the upper level folder and then trying to run your program. You will get the following error.

Quote

Unable to copy file "C:\Documents and Settings\Jason\Desktop\Project1.NET1\schedule.mdb" to ".\bin\schedule.mdb". Could not find file 'C:\Documents and Settings\Jason\Desktop\Project1.NET1\schedule.mdb'.

So everything is working correctly, just need to figure out why it is copying the database each time the application is run.

To be honest, I've never added bound controls to a database in the manner that you have done with this application, I always hard code my connections and data bindings.

I will keep looking to see what is causing the program to copy the database. I will let you know if I can find the problem.

[Jayman]

Alright, now we are getting somewhere.

I found where the problem is located.

Here is what you need to do:

1. Select the database inside the Solution Explorer
2. In the properties window, in the property labeled "Copy to Output Directory"
3. Change it from "Copy Always" to "Copy if newer"


Now run your application, make a couple of changes, close it. Now open your application and you will see that all the changes made to the database are still in effect.

[EOgre0152]

jayman9, on 2 May, 2007 - 11:02 AM, said:

Alright, now we are getting somewhere.

I found where the problem is located.

Here is what you need to do:

1. Select the database inside the Solution Explorer
2. In the properties window, in the property labeled "Copy to Output Directory"
3. Change it from "Copy Always" to "Copy if newer"


Now run your application, make a couple of changes, close it. Now open your application and you will see that all the changes made to the database are still in effect.

That does it!!



Awesome, thanks a lot. It figures my entire problem would be something like that. I appreciate all the time and effort you've put into helping me. I can't thank you enough.

The only peice left for me to fix on this program is printing. I know how to do printing the new way and it seems WAY overcomplicated. All I need to do is print a text file. Isn't there some easy way to just tell it "Print(textfile, default settings)" or whatever. The book I have has me splitting all the text up into seperate pages, passing loads of information, and finally sending x jobs to the printer per page. Why would they change this funtionality for the worse (at least IMHO)

[Jayman]

Yes its true printing can seem like a difficult process. However, I think you will find a pretty good and easy example of how to do it with the sample project at the following link.

You could pretty much incorporate the code easily in your project. With the exception of using the OpenFileDialog, which you probably won't need. You will probably just need to give the path to the StreamReader object of the text file you need to print.
http://getdotnetco.w...ownloadPage.htm

Anyways download the project and check out the code. I think you will find it useful.

[EOgre0152]

Yet another problem solved. Again I thank you for your assistance, it is greatly appreciated.




"Be careful when you stare into the abyss, for the abyss stares back into you."