I have upgraded from access 2010 adp to 2013 accdb and encountered several challenges. I have a Main Form that has one Sub Form. The Form is coded to allow either new records or bring up all the current records. They are linked by the Primary Key from the Main Form. The sub form is based on a query, but the form won't display if I use the query. The query is updatable. When I switch the recordsource to the table, it displays, but I am not sure it's properly linked. I say that because I have a CBO that won't display any data which is linked to a field on the main form. Works fine is sql, but not in the form. It all worked, of curse, in access 2010.
If Forms!FrmRequest.NewRecord = True Then
reset_unbound
cmdEmail.Enabled = True
Forms!FrmRequest!SfrmReqeust.Visible = True
Once the Main Form information is entered and the PK is created, the Subform has a one to many relationship (table used by main form and table used by subform). My theory is that because the table and query are linked to the backend (SQL Server), the keys aren't getting updated to link the new recordset. If this is the case, how do I programmatically relink the table/query?
did you set the link master and child settings correct?
this one:
So, by setting the above, then the sub form will only show correct related records.
However, in code, if you shove in, and set the data source of the sub form, then sometimes the above two link master and child settings can be lost.
but, as long as the correct so called foreign key value in part of and included in your query? Then you should freely be able to base that sub form on a query, or a directly to a linked table.
And note that ZERO code is required to set the FK value if you use the above, and this includes linked tables to SQL server.
So, access will set, and insert the FK value for you, but you have to tell access what column is to be used for linking up the relationships.
With above, then if you filter or load the main form to ONE record, then the sub form should correctly show only the correct child reocrds.
and if you add a new row to the sub form, it will insert and set the FK value for you automatic without code.
Related
Currently, I am trying to move from an Access backend to a SQL backend for my database while still keeping the Access form as the frontend. This is done via linked tables with ODBC connections to my backend. The form is designed to add new records to the table. The problem is with AutoNumber. The ID was set as an AutoNumber and the form would simply display (New) while waiting for the user to add the remaining columns. I have set up my SQL data with the IDENTITY property, so it will increment once a new record is created. However, I cannot get the form to behave the same way as it did because, even though the backend will automatically add the next sequential ID, I cannot automatically fill that data into the form prior to a user actually saving the form data. Is there a way maintain the form functionality that AutoNumber provides?
TL;DR: Form is not working correctly after AutoNumber is changed to Number.
Well, there are "rare" cases in which you actually need the autonumberr before you save the record. For example, if you have a sub-form, then Access ALWAYS does a automatic save of the main record, and thus the autonumber is and will have been created .So a main form, and sub form (child table) will work fine, and do so without code.
Now, there are some cases in which you need the autonumber. Say you have some "code" that needs to run and spit out some child records.
The general approach is to simply execute a record save at that point in time.
So, say there is a button, or some code you need to run in the form, and you NEED the PK autonumber?
You can use this code:
If isnull(me!ID) = true then
me.dirty = false ' force record save - autonumber now created
end if
the record for above to work will have to be "dirty", but in near all cases, this tends to be the case. The "rare" exceptions would suggest that you could check me.IsNewRecord, but in most cases the above bit of code will suffice.
I can't really imagine that the "display" of some autonumber is oh so important WHEN the user is starting to enter data.
However, if you want the autonumber to appear after ANY keypress (data entry on the form)?
Simply put this line of code in the after insert event:
me.dirty = false
So, now when looking at a form, the FIRST key press by the user in any text box will force the autonumber to be generated and appear. However, it is a VERY bad practice to assign any meaning of the autonumber ID to the end users. In fact that ID should in most cases be hidden.
the only issue or downside of above is of course that if you have any required columns, then the above may error out or case an issue.
Solution
For this problem, I needed to set my identity_insert to ON in the SQL backend. Here is the code to do so:
SET IDENTITY_INSERT tableName ON;
Also, if you get the error: Table <Table Name> does not have the identity property. recreate the table with the autoincrementing column having an identity.
Example:
CREATE TABLE new_employees (id_num int IDENTITY(1,1), fname varchar (20), minit char(1), lname varchar(30));
More on IDENTITY in Microsoft offical documentation: here
I have a contact database, created on SQL server. An example of its many to many relationships is below:
1- Contact table (ContactID, Fname, Lname, ...)
2-Contact_Skill table (ContactID, SkillID, Score)
3-Skill table (SkillID, Skill_name, Skill_type)
For easier interaction, I linked this databse with MS access file (which will be the interface, used by users). Users mainly use it for insertion, and I have somewhere else a SQL report server to retrieve some data and do some reports.
My issue now is that, I'm trying to find an easier way (without programming) to insert data in the intermediate table (Contact_Skill), other than getting the IDs manually. A thing like a drop down menu, that enables the user to choose the skill and it turns into its ID. Any easier way would be so welcomed as well. Thanks
Ok, you likely don't need code, or at the very least VERY little code, and you certainly don't have to write code to insert the records.
So, I would create the form (bound directly to the linked contact table.
So, you can use ctrl-f, or whatever to search, find, jump to your record you want to edit. (so built in search features will suffice for now).
In that form, you will drop in a sub form. (a continues form - multiple items would work nice here.
So, in that form you have this:
In this example, I have
customers
Invoices
Invoice details
So, really, I have near example the same kind of setup. One master table (customers)
Then a child table of invoices.
And then for each invoice, we have details of the invoice.
So, your main form will have that sub form dropped in that shows the contact skills.
In my case, I have this:
So, for this, you not really written any code.
Now, do note that for each invoice (or your case of contact skills).
Note how I have a edit button in that continues form.
This allows our "drill" down.
The code behind this button is:
if me.Dirty = true, then me.Dirty = False
docmd.OpenForm "frmInvoice",,,"ID = " & me!id
So, clicking on edit will launch a new "main" form based on invoice (or in your case skills) the ONE record.
Now for that skills record, it not clear if you have another drill down (child table), but lets assume you do!
so, In that form, you simply drop in another sub form (again continues items), and you thus are now free to add more skills to that one contact skill.
In my case, it is invoice details, so we have this:
The above screens are rather crude (they are test scenes), but it shows a design in which you dealing with 3 typical related tables.
So the whole system works with about 6 lines of code. Just keep in mind that when you drop in a sub form to relate child items? Access will setup the foreign key value that belongs to the parent table that has the one "main" record, and that sub-form of child records. All that is required is that the link master/child setting is setup correct. Once done, then Access will manage and set the correct values used to relate the tables to each other, and you don't have to write any SQL or even any code for that matter. (you are free to add a sub form record, and then hit Edit button for further details to edit, or as noted add more child records to that form you just launched.
So related tables, and adding of child records is VERY automatic in Access, and you don't write code to add the records - access will do all this work for you if you follow the above design pattern. About the only code you ever had to add is the the "edit" button to launch the next form in the sequence.
I have been tasked with create a tracker for company work flow.
I have 10 tables with data in them. There are attributes all the tables have in common. I made a table with those attributes, giving those records a unique ID that could join them to the unique attribute records of the original tables. I am also linking a personnel table to the original tables. All of these tables exist on my SQL Server back end. I Have made a query in Access that displays all the information I was given. I'm going to use the forms in access as a front end to display, edit, and add records.
The issue I am encountering is that I can not write to a query that has externally linked tables. I have spent a lot of time normalizing this data and I know I can get around it by making tables with redundant attributes in SQL and not writing to the query, but rather write to the linked tables instead. Just wondering if there is a way around this.
Thanks
In general, even without linked tables, such queries are NOT updatable.
The general approach when working with multiple tables is to use sub forms for the child tables. That way, each form is only bound to one table. (You are free even to bind such forms directly to the linked table).
Thus, you might say have a customer table and then a table of invoices. So your main form will display the one customer and is bound to that one table.
In the sub form, you can then display all of the invoices.
So to combine multiple tables into a form or screen that allows users to update the data, or add more data, you don’t build some query that joins all the data together, but simply combine several forms into one form. But each of those separate forms will display data from the given related child table.
Here is a typical invoice form thus built in Access:
The top part is the “main” form of an invoice. It is bound to the customer table – one record. Then the multiple lines of detail is the invoice details table. So the form does NOT use queries, but each part of the form and sub forms are bound to the given related tables. You are binding each form directly to the linked table (or tables if you need to show related data like above).
This approach allows you to cobble together a set of forms that edit related tables, but each form is bound directly to the linked table.
So the fact of linked tables or not is moot – such queries are not used to edit data and such queries from link or non-linked tables are NOT updatable.
So your form + sub forms will follow the pattern of related tables that you need to work together as one whole view and means to edit data. You don’t need nor want to use a query to fill these forms.
You most certainly will provide some kind of “search” form, or some means to pull up say one customer invoice, and that invoice along with its sub forms will display the related data, and also allow editing of that data.
I have an MS Access Parent form, with two sub-forms (both linking to the same table)
I am trying to use the first subform as a navigation aid (in datasheet mode) and the other sub-form is used for data entry.
What Works:
- Currently I can add new person images easily from within subform1 and subform2 refreshes once I save the record.
What is not working
- Subform 2 is unbound to the person ID, so when I try to create a new record from within subform 2 the new record is not associated with the active person record.
Any Idea how this can be made to work better. (I am using a field on the main form (imageidLink) to link Subform2's master field.
Sample database can be downloaded here
I suppose the subform2 has [per_id] too:
Edit the default value property of per_id field in subform2, and put this expression:
=Forms![Person].form![per_id]
Then when you create a new record on subform2 it will be associated to active person record.
I have an excel sheet with information about each employee. I keep getting new updated spreadsheet every month. I have to create a database managing cases related to the employees. I have a database and the bounded form already created for the cases which also contain emp info fields. What I am trying to do is to only type in the emp id in the form and want the form to look up in the spreadsheet(which can be a table in the cases db) and populate other fields in the form and that information can go into the cases db. Can this be done?
Assuming the Employee information is available within the current database, perhaps in a linked (Excel), table there are a number of ways to approach this, one of which is:
Create a form based on the Employees table, showing the fields that you are interested in auto-populating
Delete the RecordSource of the form
Delete the ControlSource for each of the controls on the form. You need to do this otherwise they will all initially display with the error #Name?
Set the Locked or Enabled property of these controls to Yes or No respectively, so that the information they will display will not be editable
Add a, for example, Combo Box to the form; you can accept the third option in the Controls Wizard to help you populate this. You need the EmployeedID as the first column, but can add additional columns
Delete the Embedded Macro that Access creates (or Macro for Access 2003 or earlier) for the AfterUpdate event
Click the build button for this event (...) and create some code.
Here is some code I used with my sample Staff Database:
Private Sub cboStaff_AfterUpdate()
Me.RecordSource = "SELECT StaffID, Title, FirstName, Surname FROM " _
& "tblStaff WHERE StaffID = " & Me.cboStaff
With Me
.txtStaffID.ControlSource = "StaffID"
.txtTitle.ControlSource = "Title"
.txtFirstName.ControlSource = "FirstName"
.txtSurname.ControlSource = "Surname"
End With
End Sub
Whenever the user selects a staff (or employee) member from the combobox this will retrieve the data from the table and populate the various controls on the form. These controls will not be editable as they will be locked or not-enabled. (You can also set the Allow Additions and Allow Deletions properties of the form to No, but Allow Edits needs to remain as Yes, otherwise the combobox won't work.)
This code can be improved. In particular, to only set the RecordSource and ControlSource s once.
Obviously I am not aware of the specifics of your database, and there are other ways to approach this.
Added If, however, the RecordSource for the form is some other table that you are hoping to populate with some details from the Employees table then, instead of changing the RecordSource and ControlSource as indicated, you could use ADO (in the AfterUpdate event of the combobox) to create a RecordSet containing a single row (the chosen employee's details) and set the values (the Text) of controls on the form to the values from this recordset. As I say, there are a number of ways to approach this.
Added In response to:
"The changes you requested to the table were not successful because
they would create duplicate values in the index, primary key or
relationship...."
I don't know your precise set-up but I can tell you why this is happening. The default behaviour in Access is that, for a bound form, if a change is made to any one of the bound fields, then an attempt to navigate away from the record will cause Access to save the record.
Is the form bound when it doesn't need to be? Or have you set the ControlSource of a control to a field when it doesn't need to be? If this is not the case then:
In the BeforeUpdate event of the form you can set the Cancel argument to True to prevent the update (or insert). However, this will prevent ANY new record from being inserted. You can either have a Button that the user needs to click to explicitly save the record, or, in the BeforeUpdate event, test some condition with If to decide whether you will allow the insert (or update) or to stop the record from being saved (by setting Cancel = True).