I would like to delete a record from my table using grid view, I have tried many different ways of doing this however when the form is closed and re-opened the data returns. (Just the form not the program)
I am aware that visual studio resets all changes once the program is closed. My add and modify data buttons are both working fine and if I close the form and reopen the changes remain. However I can’t seam to do the same with delete, unless I am missing something obvious =S.
These are the routes that I have tried, I am coding using visual basic.
Method one:
StudentBindingSource.RemoveCurrent()
Method two:
BindingNavigatorDeleteItem.PerformClick()
To save new data I use the following which works fine:
StudentBindingSource.EndEdit()
StudentTableAdapter.Update(Database1DataSet)
If I remove a record using one of the methods above and then click save I get the following error:
Update requires a valid DeleteCommand when passed DataRow collection with deleted rows.
Related
I decided to "tweak" an existing database to further manage multiple sources of income.
I copied the working database and created a "modification copy", just in case I messed things up horribly.
In the modified version, I have a button on a form (in fact, two different buttons with similar macro properties, just directed to do the same function to different reports.
The properties are your standard macro with an openreport, and a "where" condition.
Here's the problem. The macro has worked in the past, and continues to work on my "pre-modification" operating database.
On the modified database, after ensuring all the parameter elements are entered correctly, I can change the "view" to report view, and the macro seems to work just fine until I close the database.
As soon as I open the database, the buttons produce an error. See pic below.
The only way I seem to be able to resolve this odd button macro issue is by going into design view and adding a new button. I've discovered...I don't even need to embed a macro, just adding a new button seems to renew the macro operation...until I close and reopen the database. Then, I have to add a new button again to get the open database's macro to operate.
I can delete the new button added, and still have the macro buttons work, until I close and open the tweaked database.
I have zero VBA coding knowledge. I use Access's macro building tools and typically have to visit sites like this if I need to learn a new "trick" to get my database and it's various tools to do something.
I recently explored with the "subform" that can be seen above in the open form pic with the error message. My guess is that maybe that subform is somehow causing my macros to continuously fail???
Thanks for any help!
Edited / re-written due to jmcilhinney's comment...
I have a project which uses several DGVs bound to an Access db. The form designer show 3 data sets for some reason, even though the solution explorer shows only one and all the tables are shown in that one data set's designer.
I can edit the first DGV but not another on the same form, the first is filled with the following...
Me.PingMonitorPLC_IPsTableAdapter.Fill (Me.PingMonitorDataSet.PingMonitorPLC_IPs)
And the other is filled with the following code...
Me.ActiveAlarmsTableAdapter.Fill(Me.PingMonitorDataSet1.ActiveAlarms)
jmcilhinney's comment is that I must be doing something wrong, the form load event only runs the code listed above.
I dont know why I have 3 data sets listed on the form designer and I am too scared to go deleting things as I have lost an entire project before because I corrupted the designer by deleting controls etc.
Building a Maintenance log book in access. Had to redo a data entry form so I started over with a new form in a new database then copied some working code from the old form to the new. In doing so I changed the names of a couple of combo boxes in the new form in order to keep things consistent. Problem is, the code I copied has the old name of some of the combo boxes and I can't change those names to the new names. The new names don't present when using autofill, just the old ones. Is there a way to correct that.(Easy, I Hope)
Example: in the old form the name of a combo box was actionCB. In the new form the box is named ActionCB, but now any code I write uses the old name.
This might be happening because you have compilation errors. Try compiling the application and fixing any errors. Or possibly this could happen if you happened to be stepping through the code at the same time (but I doubt it from your description)? Also VBA is beautiful in the fact that almost always you can make code changes while stepping through the code... but I've experienced the changes not saving from time to time.
MODIFIED FOR NEW QUESTION
As to your second question below in the comments. You can view and select a Form or Reports controls by using the Forms Property Sheet. If you look at the combobox at the very top of the property sheet it lists all Form or Report controls. You can select these objects by simply selecting them from the combobox.
Access is not case sensitive
"Example: in the old form the name of a combo box was actionCB. In the
new form the box is named ActionCB, but now any code I write uses the
old name."
If you're code is not updating to reflect the "ActionCB" name automatically, then you're probably trying to reference it where it's not available. This isn't going to generate an error if you don't have Option Explicit statement at the top of your module.
It'll just assume you know what you're doing and assign it to a Variant data type.
Put Option Explicit at the top of all your modules, and the debug | compile untill all errors are fixed.
To start, I am using Access 2003 and have a similar project that works correctly that I designed.
I am stumped as to why a particular field will not change dynamically like every other field until I "refresh".
Currently I have a task list that lists all items that need to be works. Containing a Status: New, Open, Closed; The account number, person who is working it and more.
The tasklist is just a form with a subform with a datasheet view that opens the task when you double click it. If a user opens a task, that task will be locked until they move on. If any information that is viewed in the task list is changed, it dynamically updates, all but the Status (which really is the most important) until the user manually refreshes it.
Does anyone know what I need to look for that would cause this? The Status is stored as an integer that joins with it's true value. I thought this may be the reason, however I have a similar tool I designed does not have this issue.
I've look into how they are joined, the code that changes this value, everything seems the same between the working and not working.
Any advice?
Thanks in advance.
edit any fields that are JOINED, do not seem to dynamically update until I hit refresh. However, the other database has this working. What am I missing that is different between them.
Solved.
I changed the object displaying the field from a textbox to a combobox, showed two columns with widths 0";1" and it works.
I have a VB windows Form project that connects to several DataTables in an Access DB. On my form I have several textboxes, comboboxes and datetimepickers that are bound to those sources. With one table in particular when I try to update the tableadapter after editing one of the textboxes the update method fails. No exceptions are thrown, but the update method returns a zero value and the data is not updated. The update will work when just the comboboxes or datetimepickers are edited, but as soon as a textbox is edited also, update will not work.
Other DataTables within the project are set up in the same manner but are not having update issues. I can't figure out what about this one particular table is causing an issue. Can anyone give me any thoughts on where or what to troubleshoot?
Thanks!
try adding another textbox or other control pointed to the same source and see if you can get that one to update. Could be something funky with the control's settings that you're missing, and if you start over, it would be fine.