I have an Access form that lists all records in a table. One column in that table refers to a 'device' table, which then has a foreign key reference to a 'brand' column. In the form, the brand name + device name are displayed due to some magic in a combo box for every row.
The question: how can I sort this form by the brand name, while still retaining the ability to create new records? This is my current query:
SELECT ehs.*
FROM ehs, brand, device
WHERE brand.ID=device.brand_id AND ehs.device_id=device.ID
ORDER BY brand.brand_name, device.model;
Apparently (and understandably), you cannot add records when the query has a join in it. What would be a better approach to sorting the list?
You can create a form that has a foreign key in the query that allows adds and updates. I've just done this in Access 2010 to confirm.
It's possible that some of the magic you mentioned with the combo boxes has broken the ability to do so.
Note: I've just noticed I've used DeviceName where you've used model - you'll need to adjust the SQL below.
There are some tricks, though:
Make sure all of your tables have primary keys (hard to avoid in Access)
Make sure all your foreign keys are indexed (so brand_id in device table, and device_id in ehs table) - duplicates ok.
Use the relationships diagram to draw the relationships between these tables
I then created a query - I just used the query designer, so Access' interesting brackety arrangement is all its own doing:
SELECT ehs.*
FROM (Brand INNER JOIN Device ON Brand.brandID = Device.BrandID) INNER JOIN ehs ON Device.DeviceID = ehs.DeviceID
ORDER BY Brand.Brandname, Device.DeviceName;
If you view that in a data sheet view you should be able to add a record. That's important, if you can't there's a problem, if you can then we're on the way.
If this works, then I'd suggest create a new form based on this query and verify that the new form allows you to add records. This new form is basically going to have an id number for device_id. So you'll have to type a number to make it work.
The trick you're going to want to perform is, and I'm guessing the thing that's causing you problems:
To have a "brand" drop-down that you choose a brand, which then limits the options for the device drop-down.
That's REAL tricky (and I'm afraid I'm somewhat rusty in Access, and it's not in the question, really).
What you CAN do, easily, instead, is have a drop-down for device, that includes the brand name, and sort that appropriately.
I added a combo box to the form. The wizard takes you through using a table or query, I just chose the device table (we'll tweak this later), and the fields - you need device_id model and brand_id, and what to display (model and brand_id - we'll tweak it) and it hides the primary key. When it says "do you want to save it for later or store it in this field, choose store it in this field and choose device_id (which is in the ehs table).
When the wizard completes, click on the new combo box, and get the properties for it. Switch to the Data tab, an there's a builder [...] button next to RowSource. Click that, you get a query builder. Add the Brand table and show the brand_name field and hide the brand-id field. (We just chose that so the combo box has two columns). Sort as you like.
When you close it, it will ask you if you want to save it, so say yes. Your SQL will be something like (with appropriate field name changes because of my mistake):
SELECT Device.DeviceID, Brand.Brandname, Device.DeviceName
FROM Brand INNER JOIN Device ON Brand.brandID = Device.BrandID
ORDER BY Device.DeviceName;
Your form should now have a combo box that shows the device name when not selected, and device name and brand name when you select the drop-down.
You can then delete the original device_id text box from the form.
And you can also add the brand name to the source query and add it as a text field on your form, so you can see the brand next to the device, even when it's not in the drop-down.
The primary query for the form can be:
SELECT ehs.*, Brand.Brandname
FROM (Brand INNER JOIN Device ON Brand.brandID = Device.BrandID) INNER JOIN ehs ON Device.DeviceID = ehs.DeviceID
ORDER BY Brand.Brandname, Device.DeviceName;
You can add BrandName as a text box - you don't need devicename (model) because this shows in the combo box.
And you should still be able to add records.
So, not ideal, but a lot simpler than coding up a bunch of VBA, which is where I think you'd need to go if you wanted to separate your combo boxes (not sure), especially as that's not the original question anyway.
I suggest you do each step and verify that it's still working at each stage.
Good luck.
Related
Background
Each Dataverse table contains a primary name column. When displayed in a subgrid, clicking on the primary name column will navigate to the form so that the user can edit that row. Most subgrids in my application work this way.
The Problem
I have a Course form with a list of participants displayed in a subgrid. The subgrid displays each student's name (as a link) and the grade received in the course. There is no appropriate primary name column for this Participant table. To edit the participant record, the user must select the row in the subgrid, then click the subgrid's Edit button. As a result, this UI is different from all other subgrids in the application and I know that user's will click the student name to try to edit the participant record and be confused when they are presented with the student record.
Am I missing something? Is there a better way to handle this?
It's a common problem I face quite often. Here is usually what I would do.
Make sure the Primary Name Column always contains relevant information to the user to be able to quickly identify a record. Sometimes it requires copying information from one or multiple other columns into the primary column.
In your case that would probably means concatenating the student's name and grade.
How to do that?
Common to all solutions below
Use one of the following solution to copy the content of one or several fields into the primary column.
Make sure the solution you select also updates the content of the primary name column when one of the copied field is updated.
Remove or hide the primary column from the form, the name of the record will be displayed at the top of the form anyway and you probably don't want users to play with it.
Display the primary name column in every subgrid.
I would recommend not adding the fields copied into the primary column in the subgrids to avoid confusion.
Solution 1 - Classic Workflow
Create a classic workflow that runs when a record is created / updated
Pros:
Very quick to put in place
Runs synchronously (users will see the name updated in real-time)
Cons:
Not very practical if you need to add business logic (using different fields as source depending on a certain condition for example)
Solution 2 - Power Automate
Create a Flow that runs when a record is created / updated
Pros:
You can implement complex business logic in your Flow
Cons:
Runs asynchronously (users will have to refresh the page after the creation of a record to see the record's name)
According to Power Automate licensing that flow would certainly be considered as an "enterprise flow" and you are supposed to pay 100$ / month. That specific point must be taken with a grain of salt. I had several discussions with Microsoft about it and they haven't given me a clear answer about what would be considered an enterprise flow.
Solution 3 - Plugin
Create a plugin that executes when a record is created / updated
Pros:
You can implement very complex business logic in your Flow
It can run synchronously
Cons:
Pro-code (I put it as a con since Model-Driven App is a low-code / no-code approach but there is nothing wrong about pro-code per say)
Developing a new plugin for each entity where you need this logic is kind of overkill in my opinion. I would consider developing something very generic that would only require some sort of configuration when the logic needs to be applied to a new table.
Overview
I have inherited a website that allows users to order customised products. The customisations were saved in a way that disassociates them from their record. I would like to modify the db so these records can be associated.
Example
Users can get Product #1 "stock", or customise it, changing as many as 10 different properties. Let's say color, fabric, width, height etc.
Orders can, and regularly do, contain multiple products, each of which may be customised.
Additionally, users can save their orders, so they can re-order later.
When the database was designed, the details of the order was neatly organised into individual columns. Customer name, address, payment type etc. But the list of products and more notably their customisations were saved as a JSON string in a single column. For ease, let's call this column the "cart".
Basically, the order table has a column cart and the cart column contains a JSON-formatted list of products and customisations.
Unfortunately, the JSON object has reference ids to the product table, but lacks references to the customisation table. Instead it uses a bunch of strings meant for a human to read. Fortunately those strings exist in the customisation table, but they were written as the cart was created.
The problem we face is that the list of customisations can be changed by a CMS. So far, they haven't been changed. 🙏 But they will need to be soon and that's going to cause problems:
Problems
If a customisation option is removed (say, a fabric option) and a customer re-orders from an old saved order, we need to be able to parse the cart, detect this and warn them of the change.
Customisations are currently immutable. Once a product is added to the cart, it cannot be changed. Users need to delete and re-add to make a single change. Poor UX.
If anyone changes the human-readable text on a customisation we're dead. ☠️
Questions
How would you design this if you were staring from scratch?
How might we go about converting the current implementation and legacy data to this new schema?
I don't know if stack is notable, but we're on Postgres and Django-Python.
I would implement this with the following tables:
Products {
productId // primary key
name
price
}
Customization_Types {
customizationTypeId // primary key
name // e.g. COLOR, FABRIC, LENGTH
}
Customizations {
customizationId // primary key
customizationTypeId // foreign key
value // e.g. BEIGE, VELVET, 8
}
Product_Customizations {
productCustomizationId // primary key
productId // foreign key
customizationId // foreign key
priceModifier // price markup for applying the customization
isValid // false if this record is invalid/obsolete
}
Orders {
orderId // primary key
customerId // foreign key
}
Product_Orders {
productOrderId // primary key
orderId // foreign key
productId // foreign key
quantity
}
Customization_Orders {
customizationOrderId // primary key
productOrderId // foreign key
productCustomizationId // foreign key
}
The Products table contains the data for your base products - name, price, etc
The Customization_Types table contains the type names for your different customizations - COLOR, FABRIC, LENGTH, etc
The Customizations table contains a link to a customizationTypeId as well as a legal value - I'm assuming that users can't enter arbitrary numerical values (for e.g. LENGTH or WIDTH) i.e. they're given a drop-down box instead of a text box, however if they can enter arbitrary numerical data then you'll need MIN/MAX fields that are null for named constraints (so e.g. you could have Type:COLOR/Value:BEIGE/Min:NULL/Max:NULL or Type:LENGTH/Value:NULL/Min:4/Max:8)
The Product_Customizations table links a Customization to a Product, so for example if ProductX can come in BEIGE then you would create a Product_Customization record that links ProductX to BEIGE.
The Orders table just contains an orderId and anything else relevant to the order (e.g. a link to the customerId and shippingAddressId)
Product_Orders links a product to an order
Customization_Orders links a Product_Customization to a Product_Order
Let's say a customer orders ProductX in BEIGE and LENGTH=8, then you would create an Order record, a Product_Order record with a link to ProductX, and two Customization_Order records - one linked to COLOR=BEIGE and one linked to LENGTH=8.
This should make it easy to modify a product's customizations without having to reload the entire product - the user can modify color to COLOR=RED without touching the length customization (delete the old Customization_Order:COLOR=BEIGE record and create a new COLOR=RED record), or the user can remove the length customization without touching the color customization (delete the old Customization_Order:LENGTH=8 record).
When reloading an old order/product you can quickly verify that the same productCustomizationIds still apply to the product in question, else flag the user. Additionally, you can flag the user if the customization still applies but the customization's price modifier has changed.
As far as converting the legacy data, I'm not familiar with Python but I do have experience with reading JSON via Java and I'm assuming that Python offers similar if not better libraries for this. The trick is going to be matching the existing data to pre-loaded Product_Customization data - if the data fails to match then create a new Product_Customization row corresponding to it with isValid=FALSE (this is assuming that the customization in question is no longer offered), and when you get a chance manually iterate through the invalid Product_Customization rows to ensure that these really are unmatched customizations and not just parsing errors.
Little improvement to Zim-Zam's answer.
Even better approach is to store not plain values (BEIGE, VELVET, 8) as customization parameters, but kind of schema from which code can build up correct view of a customization.
It could be just JSON/XML formatted text. And the entity that is responsible for building view and applying logic should be able to work with JSON data of different versions.
For example, if properties of a customization have changed and something new has been added, in that case you only need to change code and adjusted JSON will be saved. No need to change existing data. Also there should be possibility to read old JSON versions with old properties and work with it.
Two possible ways of what to do if you read an old entity from DB:
View builder will ignore all old properties of a customization, add new properties and set their values to default. I would go with that personally.
Old view is presented to user, but when user clicks, for example, Ok button or Finish, additional logic will check that there are old properties and notifies user that they should be removed manually or just removes them automatically.
More flexible approach that requires only code changes without touching db and allows to show user old customization properties if it is necessary.
Update:
Customizations could have two kind of properties: one that administrator can define, such as title or price, which are not frequently changed and common for all customizations and another one such as size and color which could be changed frequently, could have user defined values and are not common for all customizations.
The first kind should be stored in Customization table as separate columns. That will allow to changed such properties in administrative panel and have all previously stored data consistent.
The second kind of properties could be 1) frequently changed 2) not all customization types could have such properties. It is a bad idea to store them as separate columns because if there are huge amount of data, changing column type or adding new column could cause performance degradation and sometimes could not be possible due to incompatible types of properties.
Actually, if they are stored as separate columns, you are probably will have to change code to support new properties anyway.
My idea is that you still allow administrator to change type of such properties and add new one or remove old one through some interface. The key thing here is that you are storing JSON data like this
{
"properties": {
{
"propertyName": "height",
"propertyType": "int",
"min" : 10,
"max" : 25,
},
{
"propertyName": "color",
"propertyType": "color",
},
{
"propertyName": "anotherCustomField",
"propertyType": "text",
},
}
}
What's left to do is to implement view builders or renderers for all kinds of property type. And add a separate table with only values. You fetched a customization record from db, you found out which customization properties there are, checked which one are still valid and rendered only valid ones. If administrator changed type of customization's property or just removed one, you marked that customization's property as not valid in db and that's all the work. No code changes, no database schema changes.
I have looked for an answer here among other places but havent quite been able to find what I need to know.
I have 3 tables, Order_Details, Products_Ordered and Product_Details. The first two are being used in a master detail form to show the order and the items ordered together. The Products_Ordered table has a composite primary key made from two foreign keys, the first being the primary key from the Order_Details table, and the second being the primary key from the Product_Details table. Together they ensure that a type of product can only be added to an order once. If someone wants to order more than one product then the quantity field in the record can be altered to reflect this. All that seems fine so far.
My issue is that when adding products to the order in the master detail form i have used a drop down list of values to select the product to add to the order. the display value for this is the product name and the return value for it is the primary key for the product from the Product_Details table.
I like this because its easier for the user to simply select the product and add a quantity of it to the table. And it works fine for both insert and update operations apart from one situation.
If the user selects the same product in to rows then submits the table the database then tries to add the product to the order twice, throwing a "ORA-00001: unique constraint violated." error. Obviously this is because of the product ID being used in the primary key of the table.
I don't want to allow the user to add two records to the table like that, rather id like to force them to alter the quantity field accordingly. The error message that comes up isn't very user friendly so my question is how can I detect this error and display a more user friendly one instead telling them to alter the quantity field instead?
*If this isn't possible then is there a way that I can hide any already selected products from the dropdown list of values in the following table rows? I haven't looked into this too much because surely it would get complicated when the user tries to add more rows than products available in the dropdown and there are no more products values to show?
I am quite new to this so please be nice. Any help is greatly appreciated :D
Here is a link where all is nicely described:
https://docs.oracle.com/cd/A97630_01/appdev.920/a96624/07_errs.htm
Section
Predefined PL/SQL Exceptions
in combination with:
Defining Your Own PL/SQL Exceptions
and
Defining Your Own Error Messages: Procedure RAISE_APPLICATION_ERROR
Hope it helps...
I'm trying to build a FileMaker Pro 11 layout that excludes records containing a certain value. The relevant data is in table Invoice. I want to filter so that Invoice records whose "Invoice Check Grouping" field is blank are not displayed on the layout.
I've added a global field to the invoice table called "Blank Invoice Check Grouping" to use as my filter criteria. I've created a self-join relationship to the Invoice table, joining "Invoice ID" to "Invoice ID" and joining "Invoice Check Grouping" to "Blank Invoice Check Grouping". The resulting table is named "Invoice Check Groupings".
The layout which I build based on table "Invoice Check Groupings" shows all records in Invoice--it does not filter out those with blank values. What am I doing incorrectly?
Thanks,
Ben
Layouts show records in a table (or more accurately, a table occurrence) and don't directly deal with related data. As mentioned by #pft221, you can use relationships for filtering, but only when viewing data through a portal.
If you always want a particular layout to show data based on a particular find, you can do so with a script and a script trigger. First set up a script to do the following:
Enter Find Mode[]
Set Field["Invoice Check Grouping"; "*" // Find all records with any data in this field
Perform Find[]
Note that you can also embed the find request within the Perform Find script step, but I tend to script finds in the above manner as it's easier to see what the find request is in the script and variables can be used in the find request.
Now you need to set your layout to execute this script whenever it's loaded. Go to the layout and enter Layout Mode. Select Layouts>Layout Setup from the menu bar. Click the Script Triggers tab and check the box for OnLayoutEnter and select the script you wrote above. Now whenever the layout is entered, that script will run and exclude the records that have that particular field being empty.
There are many ways to filter records, depending on what you are trying to do and what you are trying to display for your users.
The most common and simple way you can filter records is through a simple Find in a list view. I'm unclear from your question, but my best guess is that you're already using a list view and misunderstanding how FileMaker's relationships and Table Occurrences (TO's) work.
To Filter with the "Find Records" method:
Create a new List View layout of any Table Occurrence of your Invoice Table -- most likely you will want to use the default Table Occurrence that FileMaker created for you when you created the table.
Place the fields that you would like to display on that layout, including the "Invoice Check Grouping" field.
Switch into Find Mode
Put a '*' character into the "Invoice Check Grouping" field
Perform the Find
You should now see a list of all Invoices where the "Invoice Check Grouping" field is not blank. (You can find additional interesting search criteria in the "Insert: Operators" drop down of the title bar.)
Now you may actually be looking to filter related records through a portal but, given that you've set up a self-join on the Invoice index on the Invoice table my guess is that, at best, this would show either 0 or 1 record for each Invoice record you display in your main layout.
To Filter Records with the "Portal Filter" method:
Let's assume, though, that you have a Client table where you'd like to see only the records with a non-blank "Invoice Check Grouping" value. The table set-up would be as follows:
Client
Client ID
[... other client info ...]
Invoice
Invoice ID
Client ID
Invoice Check Grouping
[... other invoice info ...]
With a relationship in the relationships graph:
Client::Client ID ------< Invoice::Client ID
From there you would set up a Form layout on the Client TO and create a portal showing records from the Invoice TO. From the options for the portal you would select "Filter Portal Records" and use a formula similar to:
not IsEmpty(Invoice::Invoice Check Grouping)
Finally, it's worth noting that a portal filter isn't appropriate for all display situations or calculations. You can set up a similar filter completely through your relationships graph (as I believe you have already tried to do.) This will work, once again, for viewing records through a portal but not for the records displayed by a layout itself.
The answers above don't actually help Ben with his question. They are workarounds.
I have the same problem as Ben, and I don't think there is a solution, even now in Filemaker 12. There is I think no way to define a relationship that will omit the related records where the match fields are empty.
Two options come to mind:
On a specific layout, you have more fine-grained control in the portal definition itself, and can use this to exclude the records
You can now use SQL queries to achieve this result within Filemkaer.
I am facing a problem while making product configurable i used this link http://www.magentocommerce.com/knowledge-base/entry/tutorial-creating-a-configurable-product/ but In associated tab the products doesnt show up
Thankds and regards
2 things you can check:
Are you sure that the simple products you want to associate to the configurable product actually have values for the attribute you made the configurable product configurable by? So if you made a configurable product based on 'color', do the simple products have values selected for 'color'?
When you are looking at the associated products tab, and seeing the blank grid there, have you tried resetting the filter, or selecting 'No' or 'Any' in the first column? If it is set to 'Yes', it is only looking for products that have already been associated.
How does configurables products linking works in magento ?
Getting rid of being trolled by the linking of configurables products with their simple counterparts ? Let's explain how does Magento link'em... and why it sometimes doesn't work as expected.
The first point to understand is how the data persistence is managed by the application. As expected, links are stored in database. Thought it was in catalog_product_relation ? You were wrong. It should be too simple to respect the Magento's spirit :)
catalog_product_relation vs catalog_product_super_* tables
I won't tell catalog_product_relation is useless – in fact, it's necessarily there for something. But from version 1.5+, this is not there that links are stored, and I can't explain what does its purpose is.
First step
The first step of the linking process is the definition of the configurable product's configurable attributes. Supposing we're creating a new configurable product from an attribute set having a few global-select attributes.
If you try to access to your configurable product, the application will ask you which of 'em should be used as configurable attributes, in a form using a list of checkboxes associated to each attribute. By selecting some and saving your product, you insert in catalog_product_super_attribute a row by attribute (an association between product's id and attribute's one).
Second step
The second step is the linking itself with the associated simple products. This step is a bit more complex, because it implies some checks of the database's content, which we'll detail further below. Some rules to keep in mind about that :
only products having the same attribute set as the current configurable product
options must be defined for the configurable attribute
only one simple can be linked for a given configurable attribute combination
simple can be linked to as many configurables as desired
Then, what happens when we go to our configurable's associated products tab ? Don't be scray to not see any of your simple-corresponding-product in the list that display – it's filter is configured by default to display only already linked products. Here is what happens behind the scene :
the application go check the catalog_product_super_attribute table, and bring back each corresponding attribute id defined there for the current product (our configurables attributes)
from them, it will go check eav_attribute to get some details about them – in which ones the backend_type, which is the more important part of this explanation
parallely, the catalog_product_super_link table is checked too. Any product linked to current_product is a potential linked product
for each attribute, the application check if a value exists in catalog_product_entity_{backend_type} for each potentially linked product. Note that if no value exists for a given product, it won't be validated nor as a potential link nor than an effective one, even if it has already been linked (we'll see below what it implies for attribute creation).
To resume, only products with a valid value are diplayable and effectively linked / linkable. Note that all of the combination must have valid values – if any of the configurable's attribute as none, game over, you'll not have any link between your simple product and its configurable counterpart.
We should think it's ok, and everything will go right now, since we know how everything works in database. That's true if you always create your attributes from the application's back-office. But since scripting attributes is a very common way to proceed, you're much like to be in this second case, which implies a potential HUGE problem.
Programatically created attributes and... What the hell !?! This attribute has change of backend type !
Edit note: this case happens effectively when using a eav/entity_attribute_source_table source model
This a trouble I personnally runned through. If you check attributes backend models in database (only for select attributes – we do not care about which ones are not usable as configurable's ones), you'll see some varchar, some int... In short, multiple ones, and we could rightfully expect any of them works.
And they do so. Since you do not decide to add an option to your attribute from the back-office, or anything else that require to click on the « save » button on the attribute page.
The point is that when you save your attribute, Magento, in it's great goodness, ask itself what is the type of the attribute you ask him to save. The point is that before anything else, it's a select. And a select has options. And options has id. Which are the values that will be put in catalog_product_entity_{backend_type}, in any case. The label is just properly ignored in that (it's stored in it's proper table and doesn't affect anything there). Only the id is used.
And what shall we expect from Magento :) ?
It just change the attribute backend type to int systematically.
So, if you have products that used to be linked and are no more, go check the catalog_product_entity_{backend_type} tables and the eav_attribute one – compare the backend type, look for values in each values table... If you find 'em in a table that does not correspond, you get your problem. You have a few ways to correct the problem, here are the both I find myself (and I really do not promote the first, which I put only for explanation purpose).
First way: get the backend type back (The Dirty Trick)
It has changed to int ? Don't care. Bring it back to what you want it to be.
Why it's dirty : because you want you user to be able to update it's attributes when he wants. If you update the backend type to varchar, for example, any label change in the back-office for an option will rollback to int as it will be saved.
Second way: let's correct everything ! (The Right Thing)
You can pass throught this... bad situation, with a bit of MySQL without harming your database. But please, first, dump it. Then you'll require 4 steps :
check that you don't already have the data in catalog_product_entity_int table
duplicate the rows of the current ...entity{attribute} table to the ..._entity_int one by using an INSERT / SELECT statement (this query can be a bit long)
update your configurable attributes (not all your attributes, ONLY the ones you know you have created and are use to set configurable products) to set their backend type to int (and never do something else again for configurable selects :) )
delete all entries corresponding to attribute in the ..._entity{attribute} table that you'll no more use (it can do pretty much entries since you can have a lot of products if you get a lot of options)
Here are some MySQL scripts, corresponding to these steps, supposing you have at start a list of the attributes codes concerned :
Check existing entries in entity int for a given list of attribute codes
-- Check existing entries to not duplicate
SELECT ea.attribute_code,
count(*)
FROM eav_attribute as ea
INNER JOIN catalog_product_entity_int as cpei
ON ea.attribute_id = cpei.attribute_id
WHERE ea.attribute_code IN(
{attributeCodesList}
)
GROUP BY ea.attribute_code
Duplicate entries from entity_varchar table (for example) to entity_int for a given list of attribute codes
-- Duplicating missed selects from varchat entity table to int
INSERT INTO catalog_product_entity_int (entity_type_id, attribute_id, store_id, entity_id, value)
SELECT cpev.entity_type_id,
cpev.attribute_id,
cpev.store_id,
cpev.entity_id,
cpev.value
FROM eav_attribute as ea
INNER JOIN catalog_product_entity_varchar as cpev
ON ea.attribute_id = cpev.attribute_id
WHERE ea.attribute_code IN(
{attributeCodesList}
)
Update attributes to never have the problem again!
-- Update missed select attributes from varchar backend type to int one
UPDATE eav_attribute as ea
SET ea.backend_type = 'int'
WHERE ea.attribute_code IN (
{attributeCodesList}
)
Remove the no more used entries from your database
-- Kill old varchar in varchar entity table
DELETE FROM catalog_product_entity_varchar
WHERE attribute_id IN (
SELECT ea.attribute_id
FROM eav_attribute as ea
WHERE ea.attribute_code IN (
{attributeCodesList}
)
)
Hope it will help all of the ones who can't make their associated products show up to get the trick!