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.
Related
My MS Access query
SELECT MSysObjects.Type, MSysObjects.Name
FROM MSysObjects
WHERE (((MSysObjects.Type)=1) AND ((MSysObjects.Name) Like "{*"));
is showing >3,000 local tables whose names begin with "{". I didn't knowingly create these.
E.g.
Type Name
1 {00191663-6977-4C13-A56F-0E0A36697A81}
1 {00191663-6977-4C13-A56F-0E0A36697A81}_shadow
1 {001E812C-A324-40AF-B3F8-9703969260B5}
1 {001E812C-A324-40AF-B3F8-9703969260B5}_shadow
My database is surprisingly large. I tried doing a compact/repair and these remain.
I am linking to a number of SharePoint lists. Are these tables needed by SharePoint? Or, can I safely delete these?
I'm using Microsoft Office 365 ProPlus Access, Access version 16.0.11929.20978.
These are SharePoint list IDs.
{00191663-6977-4C13-A56F-0E0A36697A81} is called a GUID. SharePoint uses GUIDs to identify lists (while a name is shown, what's actually used is a GUID).
I would not recommend deleting these. If size becomes a problem, note that there are multiple ways you can cache SharePoint tables, and some cache a large amount of data. You can toggle this per database, under Options -> Current database:
I currently have a Multi-Value field based on a list of e-mail address, in MS Access 2016. Both the destination table, and the table where the list is pulled, are linked tables. The ComboBox doesn't work for either Queries or Forms when the destination table is a Linked Table. It works for regular Table.
I wish to save multiple e-mail address in this field, without having to use a secondary table (this would be a better design, but would make building forms a complete nightmare, both for me and the users). The inner data storage is a CSV-like format with a ";" delimiter, automatically handled my Access.
To answer obvious questions :
I will not use a separate table as "Good Design" suggests, to not kill UX and database simplicity.
There is no VBA involved at all anywhere in that selection form.
Question : What am I missing, and what can I do to make this work in an MS Access Form with a linked table?
Here it what the selection tool from Access Form looks like :
The solution ended up being :
Unlink the table from the front-end
Re-link it
It seems like any complex field (Multi-Value, Calculated, Attachment) requires a re-linking of the table.
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.
I am reworking and expanding a somewhat complex database schema that has a small number of tables and queries but they are closely related. The only problem I had with it was that in one of the tables the 2 fields that were relating to another table were using the field name of the record and not the ID of the record.
I changed the referring fields data type from text to number and entered some data. The queries and the reports work fine with 1 exception:
There is one report that uses both referring fields. One of the fields is ok but the other one shows symbols instead of numbers. ( The IDs in my sample entries were 14 and 20 and the symbols shown were a double barred music note /alt code 14/ and the symbol for an end of a paragraph /alt code 20/ ) Investigating further I have found that if I make a query that contains the query source for the report both fields display fine, but if I add another table to that query the second field once again shows symbols instead of numbers.
I have found a workaround of this by converting those fields back to text and the id fields in the other tables to text as well. This text key will probably haunt me later on, so I'd like to make it right before it is too late.
This is all access 2010 btw. The source file was already in 2010 (couldn't open in 2007 even)
Sounds like a corruption issue for sure. I would try adding a new column and run an update query to populate it with the values from the old column (maybe use cint(indexfield)), then delete the old column.
It might also be a good idea to decompile the database. This often helps resolve corruption issues.
I am importing a FoxPro table into SQL Server 2008 using SSIS. The source data is a proprietary database that I have no control over. Let call the table I am importing Customers.
Sometimes, the structure for Customers looks like this:
ID (int)
NAME (char(30))
ADDRESS (char(30))
CITY (char(20))
STATE (char(2))
ZIP (char(10))
CCNUM (char(16))
Other times, it looks like this:
ID (int)
NAME (char(30))
ADDRESS (char(30))
CITY (char(20))
STATE (char(2))
ZIP (char(10))
CCPTR (char(100))
This proprietary database basically has 2 different versions of the database. The older version had a field called CCNUM (credit card #) that was a basic 16 character field. The newer version replaced that field with a field called CCPTR, which was a 100 character field that represented a card pointer (encrypted value for the actual credit card number).
The problem here is everytime I have to switch back and forth between 2 datasets that have these different table structures, SSIS blows up and I have to go in and manually refresh the metadata.
My question is, is there anyway I can have SSIS dynamically look for one of these fields at runtime, and based on which one is there, load the correct data into the correct table structure in SQL?
Forgive me if this has been asked before. I am still fairly new to SSIS and I tried searching for this answer but to no avail.
Thanks,
Mark
The short answer is no. SSIS expects that there are no significant changes to the meta data of its source and destination components. There are ways to programatically influence this with .NET, but that kind of misses the point.
A well-designed solution to this problem is to create 2 separate data flows that copy the data into a shared staging table. Use this staging table as source to transform your data and push it to its final data structure.
if you build your package based on the lenght (100) and tun it on the (16), you should get only a warning. Are you getting an error?