I have a form that a user will input data into, which will then send the added record to the backend of the database (I split the database so that the frontend is accessible to users while the backend is hidden). The frontend also includes a query with no filters, so that it will full portray the backend. This way, users can either input data via the form one record at a time, or add multiple records to the query (and therefore the backend) by copy/pasting from an excel sheet with a specified format (so that the data will be pasted in the same order as the fields of the query).
I want the user to not be able to edit the data/record once it is submitted, but I still want them to be able to view it in the query and/or paste multiple records in the "(New)" record row. Is there a way to make all entered records "read only" per se, but still have the ability to enter new data (i.e. make user unable to edit previous records, but be able to add new records)?
I used this forum as a reference, but the only solution I've come up with was to make the Recordset Type "Snapshot", which does all that I want, except it disables the ability to add a new record.
https://answers.microsoft.com/en-us/msoffice/forum/all/lock-the-entire-record-once-certain-textboxes-have/24f53c0a-2435-48b2-bf91-6713ff8b60ee
I've searched far and wide, but unfortunately haven't come up with anything. Any help would be greatly appreciated. Thank you!
I am new to using the front end tools/VBA in access, but I am an advanced programmer.
I have a situation where I need to record the date, and method of commute, for a particular individual on a monthly basis. What I have done so far is programatically create a form that lists every day of the month and has a blank space next to it for the user to enter in how he commuted. User only has to fill in if he/she clean commuted. The question is, how do I:
1. Select Records that have already been entered for a month and populate them to a line on my form.
2. Show a blank space for a user to enter info on any date that is not associated with a record.
3. Update any records they changed.
4. Append any new records they enter in the blanks.
I need to do this all on one form so it is easy. I cannot ask the users to navigate.
I appreciate any suggestion that might lead me to a solution. Many thanks.
A standard bound form will do that.
Use the wizard to get started and specify your table as the source.
After much testing and working (strange not find examples of this), I have determined the way to do this.
Do not programmatically create the form.
a. Forms in Access are tied so closely to accesses "form binding" functionality that there are to many limitations trying to work with a programmatically created form. It's very difficult to do.
A better solution is to programmatically create a temporary table that has the correct data structure and bind the form to that temp table.
a. thus the only programmatic part of your form is setting the bindings. Once that is done, you can rely on the form binding in Access to work easily with your Select, Update, and Append functions.
I’m trying to create a database where the operator (me in this case) receives a log and then assigns multiple people to review this log based on the various subsystems they represent. So for example, a test is run called x. Once x is run, I receive the log of x and assign five people representing different subsystems to review it. What I’m trying to do is manage all the reviews and see if any reviews are outstanding. The structure I was hoping for, and what I have implemented so far consists of the following: I have two forms in which to enter data, one for the run information that I enter, and one for the reviews that the other people enter. The problem I’m running into is how I’m able to view who has done each review. Below is a picture of the relationships I have of my database (the two letter acronyms represent the subsystems I’m assigning):
I originally was thinking about creating a query where I would be able to search by last name and show who had done what review based on whether or not they had checked the Done Review box on the review form. The problem with this was that unless a person created a review then a review wouldn’t exist at all so I wouldn’t be able to query whether or not they had completed it based on the check box. The other idea that I had was to add a check box for each sub system in the run information table and then map the check box in the review form to that check box in the run information table based on the RUN ID and Domain info they entered into the review form. I haven’t been successful in that either as I haven’t found a way to dynamically update the control source of the check box in the review form. Anybody have any ideas of how’d they’d implement this or something I’m missing? This is my first dealing with database development and I’m at a loss right now. Thanks.
The tables have one-many relationship , you can use Ms-Access to build your tables, queries and master /detail form by wizard.
You can modify it by vba code.
At least you get starting system.
Edit:
Master form: RunInformation
Detail Form: Review
Link join field between master/detail: RunId
in this case , for any RunInformation in master form , you can insert the five records assignment for each sub system
You can do all CRUD operation for master/detail
q: "What I’m trying to do is manage all the reviews and see if any reviews are outstanding."
A: add a button in the master form that filter master/detail form where status is "oustanding".
Note:
Modify structure of "RunInformation" and remove columns of the subsystem (like hw,sw,..),and add status column in the "review" Table and column for the subsystem (hw,sw).
You can do it as combo box in Review form, and status as checkbox.
My Access form has a list box that displays files the user has selected from an OpenFile dialog box. What I do is copy these list box files into a seperate folder on the network and I save this network path in a tblAttachments table. This table has a one-to-many relationship with my main table - tblIdeaDetails.
I created a query that selects records from the tblAttachments table:
SELECT tblAttachments.attachmentPath, tblAttachments.attachmentIdeaID
FROM tblAttachments
WHERE (((tblAttachments.attachmentIdeaID)=[Forms]![frmIdeaSubmission]![ideaID]));
My question is, how can I display the results of this query in that same list box when the user is navigating through the records (frmIdeaSubmission in this case, which is bound to the tblIdeaDetails table)? I've tried doing a requery, but I kept getting an "Out of stack" error.
There isn't a lot of information to go on with your question but let me see if I can help anyhow.
My suggestion is to isolate your problem and work it out before incorporating it into your project. Create a new access database and make a 'demo' of what you are trying to accomplish.
The reason I'm suggesting this is because an 'Out of Stack' error is memory related - could be related to database corruption - a whole myriad of reasons.
Microsoft Support lists a few reasons:
http://msdn.microsoft.com/en-us/library/aa264523(v=vs.60).aspx
As identified by the support page, it can be dependent upon a number of factors that are going to be present throughout the database.
All things being equal, if you have your listbox recordsource bound to the query you indicated - calling the requery method on the listbox object should do the trick. Changing the record should also force a requery if its bound to a data source.
I recently acquired this book from Microsoft Press. I currently have Office Enterprise 2007 (Access included) and have firmly decided to convert my Informix-SQL app to Access 2010. However, I'm not experienced with VBA, Macros and several other functionality my app needs. This is going to be a new learning process for me, but I must modernize my 20 year old char-based app and take advantage of new features. I have begun defining my tables and columns, but not the relationships. With INFORMIX, I join a serial (autoincrement) column with an INT column in another table. Now when I display a customers master row, I would like to automatically display all of the transactions associated with that customer in a sub-form and have the ability to add, update, query, delete on either tables. Can this be accomplished with A'10?
EDIT: OK, this is what I have done so far, defined tables and relationships:
there are more validation lookup tables to follow, but these are the main tables. So if now I create a form and specify the CLIENTES (customer table), LOTES (lot table), ARTICULOS (item table) and TRANSACCIONES (transaction table) it will create a CLIENT table as the master form and the other child tables as subforms on one screen?
Also, the reason I created a lot table is because when customers pawn or sell items, the pawnshop groups all these items into one lot, calculates the total loan or purchase amount, stores it all under one transaction and prints the ticket with a description of all the items and total amount. So I want the ability to say, if customer defaults on interest payments or does not redeem pawn, then customer forfeits all items and pawnshop may choose to sell some items to gold refinery and/or transfer other non-gold items to inventory to sell to the public, so would the above ER be adequate for this capability?
I also want to ensure that every row in every table has the same store_ID (company ID) while users are working within a specific company, as this system will be multi-company and there will be consolidated reports, etc.
This type of setup can be accomplished in any version of access going back to 1992.
The way you model these classic one to many relationships in access is to base the parent form on the parent table (note I said partent table, not a query – I going to repeat this again: you do not need a query that joins the data for you). You then create what is called a continues form based on the child table. You now have two forms, and you then can simple drag + drop in the form for the child table into the above parent form, and you are done.
In fact, if you design and setup the relationship correctly in the relationships window, then if you use a wizard to create the form, it will actually build and automatically insert a sub form for you.
So, there is some several interesting issues about the above process that you should know As I pointed above, you don't have to build any SQL query at all. You don't have to write sql to join together the data. Access will do all of this for you, and do it without any code.
So, when you navigate records in the main form, the child records will be automatically displayed and filtered for you in the sub form. (and if you add or delete or edit those child records, the correct relationship key is inserted and maintained for you, again done without writing any code at all).
In the following form, we have a classic accounting funds distribution example. In this example we are tracking membership donations. So, the top part of the form is one record based on the master table and is the donation event. I then created an continuous form. When dropped into the main form, it becomes a sub form. That form is the one on the left side, and it simply allows me to enter a list of members who donated for the above event.
The form looks like:
At this point the form will work without any code having been written.
In fact the above form I have the one main record, on the left side I have many members who made a donation. However, I also needed to split out each donation for those memebers on the left side to an to particular account for accounting purposes. (a classic check spliting that you see in just about every accounting package these days)
So the above models a one to many and then the many members also split out into many different accounts for each donation. A really incredible powerful setup, and one that has almost no code.
So, in the above I'm really doing three tables deep as a model. |And, to be fair, the right side (donations split into accounts) did need one line of code to update correctly, as access does not do this for me when you go 3 tables deep.
However for the most part, to model these classic parent to child table relationships in access, you don't need to write any code at all. You use a main form and then for the child table, you insert a sub-form based on the child table.
And as noted if you set the relationships up correctly, access will automatically stitch the two together for you, and maintain the relationship for you. So display of the child records belonging to the one parent record will display for you automatically. And this ability includes you to edit and delete and add those child records. And, thus as you navigate to a new reocrd, all of the child records and information will automatically be refreshed for the next form.
In other words all the above can be done without building any SQL queries, and not one line of code is required.
Unfortunately Stack Overflow works great for asking a question and having an answer. However, a serious of Q + A that builds on previous question we much find that StackOverflow REALLY breaks down here. I will give this a shot, and with all due respect to the great stack overflow, I am temped to suggest you try a forum based system as opposed to so. Perahps Utter access, or even the access dev forum here:
http://social.msdn.microsoft.com/Forums/en-US/accessdev
Anyway, lets see what we can come up with. I should also point out that your table design and how to relate those tables is not really a access question but simply that of database design. How this should be laid out will be the same for MySql, Oracle, FoxPro or in fact just about ANY relational database system that we had in the last 20+ years in our industry. So, this is not really a access question when you ask about how a database is to be setup.
Ok, lets see. In the above you have the LOTES table attached to customers. If you WERE going to attach (relate) the LOTS table to a customer, then you don't need the store_id in the LOTES tables since the table is a child to that customer record. Anytime you can go up to the parent table to get that information, you don't need to repeat it in the child table(s). So, that customer record you are thus relating back to already has the store id and you be able to get at that store id value any time since it is a relation (that is the whole idea of a relational database, you don't have to repeat data over and over again).
And, as you have it now, the same advice applies to the two child table to LOTES. Again they don't need the store id since by you above design they are already attached to the LOTES table which in turn is attached to the customer table where the store id is. So, in your current design ALL of the child tables below customer can and should and would have the store_id removed.
However, the above I suspect is not what you looking to accomplish here. It is quite likely that LOTES records belong to a store. If that is the case, then you want LOTES table to be child of stores.
You thus should have STORES->LOTES
The only part not clear here is if your design is going to allow one customer to be attached to more then one store. If this is a very rare case, then perhaps you adopt a easier design that either forces you to enter the customer again, or even via some copy code. While this breaks normalizing here often there are some issues like if the shipping address is going to change for different stores for the same customer, then often you save a lot of code and design issues by not normalizing in this case.
However, if you need this feature, then the reverse is also true and there is MANY advantages to normalizing this data correctly, but often more desing work up front.
If you really do want customers to have more then one store, then you need a table called tblCustomerStores. You will attach this table to customers as a child table, and this this table will have the store_id. You can then attached all customer transactions etc. to this child store table. And this Customer store table might even include perhaps payment type and deliver preferences (if they vary from store to store for example).
So, you start at
Customers->customer stores->Transactions->
And, it not quite clear what is in table transactions, but it possible that everthing else belongs below the above trans table.
And, it not clear if Articles are attached to a particular transaction or not? If they are, then articles for thus be a child of transactions.
I thinking more of
Customers->customer stores->Articles->lots
And you want Customers stores->Tranascation
And you want Customers stores->Articles
So, I think you are currently going too many tables deep. Just keep in mind that you can relate many table to the parent table just like you have in your diagram, but I think what you have it not what you are looking for