• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

List

It can be many things. Can you point us at the page for the slow list?

Usually very slow lists are down to one of two things ...

1) You have element filters on join elements, which are set to show "Recorded data" rather than "all", and the query is generating a lot of rows.

2) You have CDD's which don't use unique FKs.

-- hugh
 
Your dbjoins don't use the recommended id element as value.

Try to add an index manually (via e.g. phpMyAdmin) to the columns you are using.
 
Mmm I do not know ... how?

Troester is correct, and you problem is in using a non-unique key for Localidad. If I unpublish that element, the list loads in a couple of seconds.

Your "Localidad" join isn't using the 'id' as the join's value from the gestion table, it's using the "localidad" field. And that isn't unique. For instance, you have 12 rows in that table with "Firmat - 2630" as the localidad. So when any row on your institucional table tries to use "Firmat - 2630" as the key to join the right row from gestion, it winds up joining 12 rows. So on the first page of your main table, where you have 5 rows joining to those 12 rows ... that means 60 rows are being selected rather than 5, just for those first five, and Fabrik is having to then narrow that down to just the "distinct" ones. That whole page of results is problems trying to load up to 1000 rows or so.

The "key" that you select for a join MUST be unique, and should pretty much always be the one we put "recommended" next to, usually 'id', which is the PK (Primary Key) of that table. The whole point of PKs in database tables is to provide a unique id to reference that row with for join relationships.

So you'll have to repair your data. Your first problem is that everywhere you have select a Localidad using a name that isn't unique in the gestion table, you'll have to figure out which of the multiple rows it was supposed to join to. And you next problem is actually changing the data.

You can't just change the key in your existing join, because that will blow away all your existing data, which is stored as the "localidad", not the P (id) value.

So ... your first step would be to create a new element on the main table, called something like Localidad_new. Make it a join to the same table, only this time select 'id' as the key.

Then you need to decide if you want to go through and manually edit every row in the Institutional list and set the new element by hand, or whether you want to try and do it with a query by hand in phpMyAdmin. Which wouldn't allow you to choose which of the multiple matches to set them to, but you could (in one query) set the "new" element to be (say) the first match for a given name.

Once the "new" element is set with the ids, you'll be able to use phpMyAdmin to rename the original on to Localidad_old (or whatever), and rename the new one to just Localidad, and change the key in the original element in Fabrik.

This is way outside the scope of "standard" support, so if you need much help on repairing this, it may have to be billable work.

-- hugh
 
Hello, thank you very much for the kind answer. I need this solution. Also update the joomla and fabrik (I'm scared that it will break) and lastly, I need to place a searcher within the forms that have the element "institutions" (next to this element) for the easy search of institutions if it has already been Entered (In yesterday's attachment send a picture of what I need) Make me price! How much does it cost for me to do this?
 
Adding that "search" button would be a lot of work. You might want to look at the "front end select" option for joins, which can pop up a list with normal filters you can then use to search and select the row you want.

For doing the rest, I'll get Robbie to contact you for a quote. I'll need to take an Akeeba backup and install it here, rather than work on either your live site or a remote copy, so I can use my locally installed database management tools. I can then run the updates and do preliminary testing here, and give you an Akeeba archive of the fixed / updated site, which you can then install and test on your server.

So it won't be exactly cheap, that's a time consuming process.

-- hugh
 
okay!. Well, tell me how much it costs so I evaluate if I can do. And as soon as possible. Tell me the price without the institution search, and with the institution search.
 
Did you figure out what you need to do about joins where the Localidad is not unique?

Your first problem is that everywhere you have select a Localidad using a name that isn't unique in the gestion table, you'll have to figure out which of the multiple rows it was supposed to join to

So for example, wherever you have "Firmat - 2630" selected, it could be any one of 12 rows in your gestion table. When we convert that to an actual FK id, we'll need to know which gestion row we choose for it. Does it matter? Can we just use the first one, or the last one?

-- hugh
 
I want it to work fast and well ... as long as nothing is erased! And remain the data that they are currently. I also want to know how to find an institution quickly. (So it is not entered 2 times.)
 
I don't think you are understanding what I'm trying to say.

For each of those "Localidad" selections on your Institucional list, because you set the "value" to be the "Localidad", not "id" ... and because there are multiple rows in gestion with THE SAME Localidad, we have no way of knowing which one of those multiple rows it was supposed to join to.

As an example, if you were joining to a "people" table, and you just saved the "name" ... "John Smith" ... and there are 20 John Smith in the people table ... you then have no way of knowing which John Smith you are supposed to be joined to.

Part of fixing this is to replace the name ("Firmat - 2630") with the numeric id ... but becuase there are 12 "Firmat - 2630" rows in the gestion table, we don't know which one to use. So you have to make a decision on how to handle that. I can't tell you. I don't know whether it matters which of those 12 "Firmat - 2630" rows your Institucional rows join to.

-- hugh
 
To try and explain with a simple example ...

Say you have two table - invoices and customers ... and in the invoice table has a join to customer. You save that join data as "John Smith", which matches 20 customers. If all you need is the name, that's OK. But if you needed to then get the shipping address form the customer table ... you'd be screwed, as you wouldn't know which John Smith, because you didn't save a real unique "foreign key" (the PK / id of the right John Smith in the customers table).

-- hugh
 
Yes, I understand what I say, but the "individual" list is made in the same way works fine.

I can not figure out what I have to do when I use it.

I do not know what to do for me!
SORRY!!!!!
We are going to solve it, I'm sure!
 
Sorry about the delay.

I have some free time this weekend, if you are available. I'll need you available, so I can show you the issues I'm trying to describe.

Can you send me a Skype contact request, hugh dot messenger at gmail dot com, mention Fabrik in the request.

-- hugh
 
Hello, no problem

I have solved this. It runs fast. The only thing that does not work is the text finder of the lists. What will be the mistake? You help me solve it, that's all.
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top