I have defined three tables, Stores, InventoryItems and StoreItemRecords. My StoreItemRecords table has foreign key columns (StoreID, InventoryItemID) that "point to" the primary keys of the Stores (StoreID) and InventoryItems (InventoryItemID) records. The columns are named the same between the tables.
If I run a query like this:
SELECT StoreID, InventoryItemID FROM StoreItemRecords;
I get some bizarre results. I get:
1, Hammer
2, Box of Nails
3, Some other item name.
So, I am getting the StoreID, as I should. But I am also getting the NAME of the inventory item, not the ID of the inventory item. Also, it is important to note that the InventoryItemID column is defined as a NUMBER, not TEXT.
So somehow, Access is trying to help me by providing the InventoryItemName in place of the InventoryItemID, but I can't seem to find the cause of this behavior or any way to stop it.
[one more note. I have written some VBA code to populate the StoreItemRecords table and, in debug mode, I can "watch" the InventoryItemID values being assigned to the column, and I have verified that the IDs are actually being put in there.]
Has anyone seen behavior like this? I know I am going to feel really dumb when someone points out the goofy thing I am doing to cause this but, at this point, it is worth the embarrassment.
Thanks in advance for any help you can provide.
My money is on one of the fields being setup as a “lookup table” in access. These are generally considered to be a not so useful feature of access trying to help novice developers who find it hard to grasp how a database works.
If you go into the table in design mode you should be able to verify if that is set on the fields in question. If it is turn it off and try the query again
Here is a link on why they are evil
http://www.mvps.org/access/lookupfields.htm
Related
I have learned more, and was compelled to find the solutions, mind changed.
PS dear experts, your help is appreciated in the time-saving nature of having forums and discussion in the first place, and also is mined for usefulness, not street cred. get helping or get off. The time I wasted reading posts where the answer was "I don't understand what you are trying to do..." and then questioning the OP with animus or incredulity, or suggesting some unrelated answer further confusing issues, is seemingly the problem with the world these days, if you want to help, help
Original Post:
Ok so as per the comments, thanks to ANYONE who volunteers any help with this problem.
I have a table and relationship design problem.
I have a table with a pk auto and I want to have a related table with a related column incrementally numbered that updates every time new data is entered in the form that is bound to it. It needs to update the related rows in the autonumbered table's key.
---the answer was to join the table on the autonumbered field.
The autonumber of the first table (main recordsource) is just an ID. I think I need two Primary Keys as I need to update the related record with that number in the entry form and move to NextRec but update the pk in the main table and move to NewRec , how do I join (see jpg image)?
I want enter results and update that existing record but update the adjoining pk so that a new record is created in the main table.
Tourney
more in depth:
From yours
My desired form
note that the calculation table feeds the upcoming games table, where a query shows the players recent results. I would like to split the upcoming results to show the players' recent game history, the second tab I would like to enter either one result or many results at a time. I hope I am clearer. You can see why I have had a challenge. See my form though. The recordsource is the upcominggames table and the data entry form is for input (ENTER GAME DATA)
-----the answer to this was an update query (a separate form) and then requery the statistics form to show the new matchups that were entered.
As from the comments, this is what I'm thinking of when I read your description:
Since the UpcomingGames will be entered first and exactly one GameResult can be entered per UpcomingGame, this will be a 1:1 relationship. As the name Upcoming says: The Upcoming data has to be entered before the Result can make sense. Unless an UpcomingGame can be cancelled, there will indeed be a Result for the Game, so there is no need to separate the information into 2 tables. I'd say, a user interface could look like this:
As you can see, the T_NUM column is an autovalue. Before entering any data, I initialized that column using a query like this (and deleted that record afterwards):
INSERT INTO Games ( T_NUM )
VALUES (1004);
This way, the numbering started with number 1005.
You won't be able to to avoid gaps in the numbering, as long as the users can remove existing records or cancel the insertion of a new record. If you want at least to avoid the latter, you will need some VBA code in the form.
MySQL 5.7
I know squat about databases but I do have a custom program that uses the databases I have. If I want to use another account (twitter) with my program, I need to make all the datasets. I've done this a few times before. It always takes me a while to figure out, but I get there.
Yet this time I'm stuck with a read-only dataset.
What I usually do is I make a new schema with a proper name.
I then go to one of my other schemas, export what I need ('sources' and 'entries') and import them to my newly made schema.
That should work and it looked like it worked again this time. BUT there is a difference... It's read-only and I am way to green to tackle this on my own. I'll try to investigate a bit more myself, but some help sure would be appreciated : ) The warning is: "read only: the table has no unique row identifier (primary key or a NOT NULL unique index)": I couldn't find any results with this exact warning so I thought to post it here :)
Thank you!
Devvie
See my comments above on how to solve it.
TL;DL - if you are stuck with a read only schema after importing your data, you might want to tick the correct checkboxes for your schemas. Select schema, select Wrench Icon and match the table to be the same as the schema's table you imported from.
Thank you all.
I recently just got a job at a call center and they have asked me to make their database more efficient and capable of storing and retrieving their information quickly. I get to build a completely new database for them. The problem is that im not that great at sql quiet yet. But if you could take a look at the picture could you help point me into the right direction or give a few tips. All the data of business and customer info is all stored in one big table with like around 40 columns. Im sure there is a way to normalize this data. Thanks ahead of time.
I don't know enough about your data to know for sure what isn't normalized right now.
The purpose of normalization is to make sure there's never a case where the same value is stored in two different places in the database.
So, if a particular company might have 10 leads, and each of those leads would have the same company_name and employee_size and sales_volume then there's a problem: each one of the 10 leads could potentially have different values there. One is "Company A", another "company A", another "Company A.", etc.
Instead, you should have a company table with those values, and a foreign key from your lead to that company. Now it's fine to have lots of leads with the same company because they're all referring to the same underlying company data.
Only you know which values in your data set might be repeatable and thus which to eliminate.
Apologies if this is redundant, and it probably is, I gave it a look but couldn't find a question here that fell in with what I wanted to know.
Basically we have a table with about ~50000 rows, and it's expected to grow much bigger than that. We need to be able to allow admin users to add in custom data to an item based on its category, and users can just pick which fields defined by the administrators they want to add info to.
Initially I had gone with an item_categories_fields table which pairs up entries from item_fields to item_categories, so admins can add custom fields and reuse them across categories for consistency. item_fields has a relationship to item_field_values which links values with fields, which is how we handled things in .NET. The project is using CAKEPHP though, and we're just learning as we go, so it can get a bit annoying at times.
I'm however thinking of maybe just adding an item_custom_fields table that is essentially the item_id and a text field that stores XMLish formatted data. This is just for the values of the custom fields.
No problems if I want to fetch the item by its id as the required data is stored in the items table, but what if I wanted to do a search based on a custom field? Would a
SELECT * FROM item_custom_fields
WHERE custom_data LIKE '%<material>Plastic</material>%'
(user input related issues aside) be practical if I wanted to fetch items made of plastic in this case? Like how slow would that be?
Thanks.
Edit: I was afraid of that as realistically this thing will be around 400k rows for that one table at launch, thanks guys.
Any LIKE query that starts with % will not use any indexes you have on the column, so the query will scan the whole table to find the result.
The response time for that depends highly on your machine and the size of the table, but it definitely won't be efficient in any shape or form.
Your previous/existing solution (if well indexed) should be quite a bit faster.
I am pretty new to this so sorry for my lack of knowledge.
I set up a few tables which I have successfully written to and and accessed via a Perl script using CGI and DBI modules thanks to advice here.
This is a member list for a local band newsletter. Yeah I know, tons of apps out there but, I desire to learn this.
1- I wanted to avoid updating or inserting a row if an piece of my input matches column data in one particular column/field.
When creating the table, in phpmyadmin, I clicked the "U" (unique) on that columns name in structure view.
That seemed to work and no dupes are inserted but, I desire a hard coded Perl solution so, I understand the mechanics of this.
I read up on "insert ignore" / "update ignore" and searched all over but, everything I found seems to not just skip a dupe.
The column is not a key or autoinc just a plain old field with an email address. (mistake?)
2- When I write to the database, I want to do NOTHING if the incoming email address matches one in that field.
I desire the fastest method so I can loop through their existing lists export data, (they cannot figure out the software) with no racing / locking issues or whatever conditions in which I am in obvious ignorance.
Since I am creating this from scratch, 1 and 2 may be in fact partially moot. If so, what would be the best approach?
I would still like an auto increment ID so, I can access via the ID number or loop through with some kind of count++ foreach.
My stone knife approach may be laughable to the gurus here but, I need to start somewhere.
Thanks in advance for your assistance.
With the email address column declared UNIQUE, INSERT IGNORE is exactly what you want for insertion. Sounds like you already know how to do the right thing!
(You could perform the "don't insert if it already exists" functionality in perl, but it's difficult to get right, because you have to wrap the test and update in a transaction. One of the big advantages of a relational database is that it will perform constraint checks like this for you, ensuring data integrity even if your application is buggy.)
For updating, I'm not sure what an "update ignore" would look like. What is in the WHERE clause that is limiting your UPDATE to only affect the 1 desired row? Perhaps that auto_increment primary key you mentioned? If you are wanting to write, for example,
UPDATE members SET firstname='Sue' WHERE member_id = 5;
then I think this "update ignore" functionality you want might just be something like
UPDATE members SET firstname='Sue' WHERE member_id = 5
AND email != 'sue#example.com';
which is an odd thing to do, but that's my best guess for what you might mean :)
Just do the insert, if data would make the unique column not be unique you'll get an SQL error, you should be able to trap this and do whatever is appropriate (e.g. ignore it, log it, alert user ...)