Hello helpful internet strangers. I have created a fairly simple database for a client that has one main entry form and a search form that uses unbound text boxes for searching around 15 fields.
Details are below, but here is my problem: When I add new records and use the search form all the fields work as expected and return the correct results in the datasheet. When I sent the database to the client and they add new records, they are not returned in the search. I had them save the database with their records and send it back to me, and I confirmed that when I search for the records they added (I can see the records in the table) they are not returned in the search. If I add new records to the copy they sent me back, my records do appear in the search.
I created the database in Access 2013 on a Windows 8 machine. The client is using Access 2010 on Windows Vista.
The field types are text, dropdown and date. The dropdowns are all based on lookup queries so they store the id number in the main info table and pull the name value from the query. All of the fields in the search query are written to allow nulls, including the date range searches. And again, all fields test out correctly on my machine when I enter the records.
I went on site and compared settings and nothing jumped out at me except the different versions. I also watched the client enter new records and she didn't do anything 'wrong' or unusual. When I try to do a save as 2007-2010 it says I am using features that won't allow for that, but for the life of me I can't think of anything like that since this is really a very straightforward design.
I'm going to do a package as executable, but am highly doubtful that will help. Any insights?
Thanks in advance.
A few things. Most important - always, always develop in the earliest version of Access that the system will be used with. So, you need to rebuild, using Access 2010, period. Try creating a new blank database (in 2010) and importing the objects one (or a few) at a time. Make sure the system is split. One file for the FE (forms, queries, reports, code, etc.) and one for the BE (tables only). Make sure that the Filter On Load property of all forms is set to No. If the recordsource for the form contains a where clause, make sure that the newly entered records meet the criteria for the where clause.
Related
Why would my form/subform mislink records using SharePoint List back end?
I have years of experience with MS Access, but this is my first time with SharePoint List as a back end.
I developed a small database for a small non-profit. Started off with Access 365 front end and back end, located on one user's computer. This ran fine and correctly for a few months, and last month we migrated the back end to SharePoint Lists so that two other users can use the database. They each have the front end on their desktop.
There's a bound form, Events, linked to tblEvents. Subform, subVolTime, on this form is linked to tblVolTime, to show the volunteers and how much time they spent at the event. In the subform property, Link Master Fields is set to tblEvents.ID; Link Child Fields is set to tblVolTime.EventID. There's no extra VBA code.
We migrated to SharePoint Lists using the wizards, and did nothing else. Shortly afterwards, my user noticed that the wrong people were showing up under events. He can tell just by looking at the names.
I created an audit query, and I can see that in some cases the dateAdded (date the record was created) in tblVolTime is BEFORE the dateAdded of the event in tblEvent. This can't be right, because you must have a record in tblEvent before an associated record in tblVolTime.
For example, there's an event ID 261, created on 4 Nov 2021. The records for the volunteers linked with this eventID were created 7 Oct 2021. Something went wonky.
Any suggestions are welcome. My ideas include: unbind the form; hide the subform until the event record is saved; create the event record before the user actually adds any data to it.
Well, hard to tell. However, unlike moving Access data say to SQL server?
Moving data up to SharePoint is VERY MUCH a different process. Why?
Well, for one, when moving data to SharePoint, the auto number PK's you have (and you MUST HAVE FOR ALL TABLES) are often re-numbered.
Now, due to this re-numbering of auto numbers?
Well, that means before you migrate the data, you BETTER really, but really and beyond really sure that a relationship was setup between such tables.
In the case of Access, while in most cases we do have a correctly setup relatonship, to be honest, you REALLY never had to do that. In other words, if I setup a master link and child link for a sub form? Well, access would just generate the PK autonumbers for the main table, generate the pk autonumbers for the child table. And THEN during a data insert would correctly insert/set the "FK" values in that child table to the parent table. As long as the link master/child settings were correctly setup (but no actual relationship was setup), then the application would happy work.
If one was to migrate the data to say SQL server? Well, since the PK autonumbers are NOT touched during this up-load process - then all relationships and their data would ALSO make a valid trip up to SQL server.
However, in the case of SharePoint? Autonumbers for ALL tables are and will and in most cases are re-generated!!!!
But, this tends to not be a problem if you up-sized the data using Access. It has built in SharePoint support, and say if a parent reocrd goes up from Access to sharepoint and the PK id is changed? No probem, since if you REALLY did setup,and you REALLY did have a relatonship setup, then the migration process is smart enough to go find the child reocrds, and update the FK values. But of course the migration process can ONLY do this magic trick if you KNOWS about the realationship.
Another simple example?
Say we have a simple form, and we have a SMIPLE combo box to pick say favor color.
tbColors
ID (Auto number PK).
Color (text color).
So, so now we have a simple form, and we dropped in a combo box. When we choose a simple color like "red" or "blue" from the combo, we of course are saving the "pk" id from the above table.
Now for a LOT of simple tables like above, never used, or bothered with setting up a realtonship. (no need - just a few choices from a combo box).
And if you were up-size data to sql server? Again, this would work fine - no problem at all.
However, if you up-size to SharePoint? You REALLY but REALLY better have setup a relationship even for this simple silly little combo box. Again, the reason is simple. When that simple table of pick list values goes up to SharePoint, the autonumber PK id's will change. And thus for any other table that used that simple pick list? You have and MUST have setup in your relationships window that this was in fact the relationships - and again, the reason is re-numbering of autonumbers.
So for ANY relationships that used PK and FK values? They MUST in ALL cases when using SharePoint MUST have been defined in the access data tables (relationships window) BEFORE you transfer that data. And again, the reason is simple - during a up-load process to SharePoint, autonumbers WILL CHANGE!!! And since they change, then any other dependent table that uses those PK values (as a FK) MUST have been part of a defined relationship. If they are not defined before migration to SharePoint, then a change in a PK value will NOT tell SharePoint to go and find and correctly update all of the "child" records or so called FK values.
So, the first question to ask is did this break in related numbers occur a long time ago (at migration time), or did this break occur due to some bad code, or the wrong values having been selected?
So, migration of related data to SharePoint is a "delicate" operation, and the main reason of course is that the related tables MUCH have been setup as enforced relationships BEFORE you migrate. If such relationships were not strict defined, then during the migration process then the relation of data based on those PK/FK values will break at that migration time.
Now, it could be a simple issue that this sub form in question does not have the correct link master/child settings - that's the first thing to check.
I've been tasked with creating a database to help with my company's annual physical inventory count. We have an ERP system that contains all our part numbers, and all of our part numbers come in boxes that have a carton label containing "part number" and "quantity" which are both barcoded. We are trying to switch to a system in which we scan all the boxes into my access database vs. our previous system of physically counting and writing tags. So far everything works great, the only issue is that some bar codes get damaged or just won't scan properly for some reason, so the scanners read the barcode as a part number that doesn't exist. We are able to export a list of all part numbers from our ERP system into an excel file which i have linked to my database that we use to see which part numbers were entered that don't exist in the system. My question is, is there a way to prevent people from scanning part numbers that don't match any part number in the excel file exported from our ERP system? I'm using ms access 2003
Using a combobox with LimitToList property set to yes is a great solution. Just to let you know that with this solution it is still possible to PASTE values that are NOT on the list. If you want to guarantee that it is not possible that the field contains wrong values, the best is that you create a Relationship (with referential integrity) taking the Table field containing all valid part numbers as the master field, and the one taking the scanned value as the slave field.
I am working on a small application in Access Services on SharePoint to log colleagues leave requests, and I need to work out a data macro to calculate how many days of leave they have remaining from their allowance.
I have a table [Colleagues] with all of the user data, for simplicity I'll reduce it to [Email] and [Allowance] in days. I have another table which stores the requests [Requests] including the number of days to deduct in each approved leave request [Days Requested].
I have set up a query that returns all approved requests for the colleague and I would like to use a data macro that is triggered to run when the colleague logs in. As you cannot use aggregate functions in Web Applications, I am currently using ForEachRecord in the query to total the number of deductible days, however I cannot work out how to return that to a field in the [Colleague] record.
According to the Access help, I should be able to set the value to a LocalVar and use it in expressions as simply as referencing [Deductible Days], however this is not working.
Any help?
I finally worked this out after much tinkering.
In my query I included the [Colleague Email] field as well as the [Days Requested] field, and then when my Application loads it navigates to a form created from the [Colleagues] table. I have modified the Data Source of the form to link the [Email] field in the query results to the [Email] field in the [Colleagues] form.
Following this I was able to create an unbound textbox with the data source =Sum([Days Requested]) referring to the relevant field in the query. Voila! I now have the value to play around with in my application.
Hope that helps, took a lot of fiddling around. No data macros needed after all, but its a method I shall remember in future, opens up a lot of possibilities.
If I understand your situation correctly, I was faced with a very similar problem.
I believe the solution used here will work for you. It involves using a query to Sum up the values (we would use Sum where he used Count), use a Data Macro to run the query and then have have an On Insert/On Update trigger the Data Macro:
http://devspoint.wordpress.com/2014/03/26/validating-data-with-data-macros-in-access-services-2013/
Let me know if this works for you. It worked for me!
I haven't done much in Access for years, but I have picked up a bit of support work to help out.
Database is an Access 2003 one, running on 2010 in compatibility mode (Behaviour was the same on 2003 though) with the data in a SQL Server 2005 backend.
We have a single form (i.e not master/subform) that is based upon a query, joining 2 tables - it's a simple organisation to address. It is theoretically many to one, but in practise one to one. I wasn't even sure if/how this would work, but it does in general.
If you create a new record (The form has a button, but it's the same if you use the built in new record button) it happily generates a new address ID from the autonumber on the tblAddress table, and populates the org_addr_code column in the Organisation table.
However if you then try and create a second new record, it throws an error
The Microsoft Access database engine cannot find a record in the table tblAddress with key matching field(s) 'ORG_ADDR_CODE'
If I hack records directly into the datasheet view of the underlying query, then it lets me add as many records as I like.
If I exit the form after inserting the first record, and go back in, I can add another record just fine. It's only if you try and do it more than once in the same form 'session'. I have tried every variation on refresh/requery I can think of, but no joy.
Anyone got any ideas? I'd rather not have to rewrite the whole form - if it came to that they will just have to stick to adding one record at a time.
Carl
I'm using MS Access 2007 as a front end and have all linked tables in SQLServer 2008 R2 backend.
In a form in Access I am trying to execute the FIND button either in the ribbon or by creating a button on the form with the expressed purpose of looking for records with a specific value in a particular field.
When I complete the entry in the FIND window, I click on Find Next. In some cases, the record(s) is found immediately. In others, it can go for hours only to report that it can't find anything (when I know it should).
The table I am looking in has approximately 99,000 records in it. It doesn't seem to matter whether or not the field is indexed.
Is there something I'm doing wrong, or is Access unable to handle this? Also, is creating a stored procedure with handling multiple search requests and passing the info to Access the answer?
The find methods are known to be slow with ODBC data sources. Here is what the Access 2007 Recordset.FindFirst Method help topic says:
When working with Microsoft Access database engine-connected ODBC databases and large dynaset-type Recordset objects, you might discover that using the Find methods or using the Sort or Filter property is slow. To improve performance, use SQL queries with customized ORDER BY or WHERE clauses, parameter queries, or QueryDef objects that retrieve specific indexed records.
Futhermore, binding an Access form to a record source of 99K records is a performance challenge. Use a query as the form's record source, and design the query to return only one or a few rows.
Give the user an option to choose a different set of rows, and modify the form's record source property to reflect the user's choice.
This depends on the type of search you need and on the data type of the column (field) to be searched. For example, if I have a text data type in an indexed column and I search using Start of field or Whole field, it will be quite fast, however, if I search for Any part of field, it may well fall over. In other words, if Access can use an index for the search, it will work, even on quite a large table, otherwise, you may be best with a stored procedure, though I doubt that will be fast without an index, either.