Having not looked at an Access db for about a decade, I find myself in need of a simple VBA (or best method) solution.
I have created a master form with two subforms.
The master form (frmProjectData) contains an autonumber ID field. It houses the primary key.
The subforms (frmFeatData and frmFutuireFeatData) are linked to the primary key via dummy (non-visible) number fields. Each subform also contains an autonumber field (not linked) that numbers each subrecord as it is entered.
The forms seem to work well together, with both subforms capturing as many records as needed and tying them to their appropriate master record. I would like to have the subforms restart numbering at 1 each time a new blank master record is opened. I recall bits and pieces of code, but nothing I've tried seems to be working so far. Any help is appreciated.
Related
I have created a database with a unique ID structure. In a form I have a subform that is filtered by a tagname that you can choose in the form with a combobox. When this combobox updates, the subform updates with the data that belongs to this tagname. The problem I am having is when editing the subform. This is because the table structure is set so that the Tagname_ID is linked with the Parameter_ID. And the Parameter_ID with the Parameter description (see image).
Now my subform is partially connected to the table tblParameters (see image).
When I edit something in the subform, it edits it in the tblParameters in the row with the corresponding Parameter_ID, but what I would actually like is that you can choose an existing parameter from the table tblParameters and the form will link the Paramter_ID to the associated tagname. I wouldn't know how to make this without changing my database structure. Any idea how this might work?
I have a sub form tied to a table. This table has a foreign key, which holds the key to different tables, depending on the value. Based on the value, the information in the record is tied to a certain object level in the schema. It may be tied to the main record based on the main entry form. It may be tied to another subform record, etc.
So let's say the main form is for projects. For each project they could be placed into many buildings. Within each building they may have multiple staff. This somewhat inter-dependent sub form is for project documents. They may relate to the current project. They can also relate to one of the buildings for the current project, but only for that current project. Or the document could relate to one of the buildings, but for all projects. I already have a combo that gets it's row source based on the relationship type/doc type combo that is chosen first. That let's the user choose the actual building, staff or whatever the doc is related to.
I need to create a filter for the sub form that will give all records related to that main record and/or it's sub records, and still be able to add new records. I've been looking at a case statement, but concerned that will only apply the first true case. I was thinking of a union, but guessing I won't be able to add records. It won't be updateable.
Any suggestions appreciated!
Thanks. I ended up creating 2 sub forms. One for viewing all records that are somehow tied to the main record. This has a record source set to a union view, with a where clause for the main record ID. The second form is for adding/editing new records and the record source is tied to the documents table, with a filter to the record being edited, or the data entry set to yes, for adding new records. This is all set based on a toggle button, new main record activity, etc.
I am migrating a horrific database from Lotus Approach '97 to MS Access 2010. This is the first time I have used access, however I am familiar with SQL.
I have a table of Events, and a table of Clients. These Clients are actually either Individuals or Companies. There is a joining table called ClientEvents which links the surrogate primary key of the Event to that of the Client. (i.e. There is a many to many relationship between Events and Clients).
My problem is that whenever I try to display the ClientEvents table for a particular Event, the result is simply a list of surrogate keys. This is of no use to my client who does not recognise these surrogate keys, however as soon as I try to do a multi-join or a subquery to select the name of the individual/comapny from the relevant table, the query/form is not updateable.
Presumably this problem is very common, as Surrogate keys must regularly be displayed next to recognisable fields from child tables?
I have tried using a DLookup in a continuous form but this is horrifically slow. Surely this kind of design is common in access? Or am I trying to be too clever implementing a proper relational design. Is access truly capable of such designs?
You should be able to use a subform (continuous or otherwise) with a ComboBox. If you're making a form for you client, make a subform with a master-child relationship on ClientID. In the subform add a combobox with a ControlSource of a query on your Events table:
SELECT DISTINCT EventID, EventName FROM EVENTS
Then on the ComboBox properties, make the Column count = 2, the column widths = 0";1" (this will make the EventID invisible and the EventName be 1 inch wide).
The ComboBoxes in your subform SHOULD be updateable. That should get you started.
Currently I'm performing a migration from a microsoft access database to an SQL Express 2010 database.
Basically, I have an Access application that searches a customer database. The access app is developed in 2 parts. An access front end on each client called application.mdb and a data backend on a windows 2008 server called data.mdb. The application.mdb has 3 linked tables to data.mdb. which holds customers and contracts and items. The customer table relates to the contracts table (one to many) and the contracts table relates to the items table (one to many)
I imported the tables from the data.mdb into the sql tables by the same name and created the same relationships and configured them to cascade. I then created an obdc connection on the clients and updated the 3 linked tables in application.mdb to point to the tables on the sql server.
I start the application and everything seemed to work great, I can see all the data perfectly and the performance increase was well worth the effort.
Then I found a problem, when I add a new customer to the database it autonumbers the customer table and the contracts table but not the items table.... Thus if I attempt to alters any of the items in the items table for new customers I can not. I get the following error "cannot add record(s); primary key for table "items" not in recordset" which makes sense because SQL had not autonumbered the items table.
I can't understand why....
Any help would be greatly appreciated.
Well, just manually adding record direct in the items view should tell you if the autonumber is working. You MUST get the autonumber working when you edit + use in direct table view.
As always these kinds of issues comes down to the details. One thing that's different when using a SQL based backend compared for access applications is the generation of auto numbers (primary key) does not occur on server based systems until record is actually saved. When working with the jet based back end, the auto number is available the instant the record is dirtied.
So I would check if you have some type of code or event running in the application that is attempting to use as primary key value before the record been actually saved.
Usually access does a pretty good job. For example when you build a form in access, and then have a sub form in access to edit child records (and a child table), then as a rule when the focus switches from a main form to a sub form, access will force a save of the main record. This thus means the primary key (auto number column) is now available for correct functioning of the relationship. Access can and will use this PK value and insert this value into the foreign key value column in this child table for you.
However access will only do above for you WHEN you correctly set up the link master and link child settings in the sub form control. As a general rule when building forms in regular access, Access can detect the settings required and insert the correct values into the link master and link child settings for you. However, the detection of the FK column will not occur with linked tables.
So when you use SQL server, you have to edit and set these values manually in the sub form control. So I would check your link master and link child settings in the sub form you're using to edit this data, and ensure that the correct values are set. If this is VBA code, then ensure the record is actually saved before attempt to use and grab a PK value.
I should point out that even in non SQL server based applications, it is the setting up of the link master + child settings in the sub form that allows access to setup and maintain this foreign key value for you. So access is always had the ability to insert these values for you, and it'll do so with you about having to write any code at all. So during the editing process to insert and maintain these values Access does all of the work for you (so it's not the data engine that inserts these FK values for you, but the user interface or in some cases code you write)
So access will not setup and insert these correct values unless you set up the link master + child settings in that sub form control.
I would simply check if your link master and child master settings are correct in any sub form control you are using here.
This sounds like a stupid answer but check the Items table to be sure that auto-numbering is turned on.
One of the things I would suggest whenever you migrate a Jet/ACE database to SQL Server is to thoroughly review the database design, e.g.: the implementation of keys and constraints, choice of data types, choice of indexes, etc. Jet/ACE is a very different thing to most SQL DBMSs so you shouldn't assume that a database design that worked well for Jet/ACE is automatically suitable for a SQL DBMS. Upsizing wizards won't always identify every possible issue.
In SQL Server the nearest equivalent of an "auto-number" is the IDENTITY property. Check to be sure which columns are IDENTITY in your tables and create an IDENTITY column if you need one.
I need to develop a front end to a MSSQL database just to modify a few tables. I decided to use Access 2003 simply because of time restraints.
I used Linked Tables over ODBC to get them into Access, I'm designing the forms but I'm having problems creating an interface to allow users to create and delete new association between entities.
My Database structure is:
product
# productcode
- name
product_part
* productcode
* partnumber
- position
part
# partnumber
- comment
There is a many-to-many relationship between product and part (a product can have many parts and a part can belong to many products) except I can't find any easy way to allow a user to just associate a new part to product, only view the existing ones.
I've defined the relationships in Access except the options for cardinality and referential integrity are greyed out, I'm assuming this is because they're linked tables? Not sure if this would affect anything.
I created a form for product with an embedded subform which lists all the associated parts and their position (position is an attribute of the relationship since it's contextual but I can spin this out into it's own table if it'll make things easier).
Basically I need to make an user interface mechanism which will associate a selected part from a list to the shown product or any other way to create new and delete existing associations flexibly. I would have thought Access would have something in some wizard somewhere to do this, but if it does I can't find it.
Any help would be appreciated.
Judging on what noted so far, then this should be a simple matter to have the main form based on your topmost table (product). The continues sub form should then be based on ONLY the product part table.
If you think about this, the third table is really only a lookup table there for your convenience to allow you to not have to type in manually type in the part number.
So, base the child sub form as a continuous form, and make that column for part number a combo box that looks up the part numbers from the third table (part). So this combo boss can search and display by description, but will in fact automatically store the part number in that colum for you.
So while there's no need for any types of wizards, you certainly do not have to write any type of code whatsoever. Just ensure that the master child link settings for the sub form are set up correctly, and access will thus insert and maintain The product code columns used to link back to the main product table. You can most certainly use the combo box wizard to create the combo box in the continuous sub form that you're going to use to Select what part and set the part number column from the parts table.
The result will be a form that allows you to add new part assemblies or edit existing. While access will maintain the product code column for you, if you delete a main record, you'll need to have setup referential integrity and cascade deletes on the back end database part. So as you correctly note, all the integrity features will be set up in the database back end, not in the access front end part.
I've discovered what I wanted to do isn't easily possible using Linked Tables, I was able to do what I wanted to do easily if I used native access tables (since it let me properly define the relationships) but I couldn't do that with linked tables.