SELECT Query fails because of restrictions or so it says [duplicate] - mysql

This question already has answers here:
Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints
(26 answers)
Closed 5 years ago.
I'm running a query against a MySQL database, and its statement is simply
SELECT * FROM tableOperationsHistory;
However, it fails and I get this exception (I translated it into English):
Fail activating restrictions. One or more rows contain values that
violate non-null, unique or foreign-key restrictions.
This is the routine where the error happens:
Public Function RetrieveTable(ByVal command_text As String, Optional ByVal parameters As ParameterSet = Nothing) As DataTable
Dim dt As New DataTable, retry = False
Do
Using comm = conn.CreateCommand
comm.CommandText = command_text
If parameters IsNot Nothing Then
Dim par As DbParameter
For Each pair In parameters
par = comm.CreateParameter
par.ParameterName = pair.Key
par.Value = pair.Value
comm.Parameters.Add(par)
Next
End If
Dim rdr As DbDataReader
RequestConnection()
Try
rdr = comm.ExecuteReader
dt.Load(rdr)
retry = False
Catch ex As Exception
retry = ShouldRetry(ex) 'EXCEPTION IS CAUGHT HERE
End Try
DismissConnection()
End Using
Loop While retry
Return dt
End Function
And this is the table definition statement:
CREATE TABLE `tableOperationsHistory` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`numero` varchar(45) DEFAULT NULL,
`pasta_id` int(11) DEFAULT NULL,
`dataHoraInicioPrazo` datetime DEFAULT NULL,
`dataHoraFinalPrazo` datetime DEFAULT NULL,
`urgente` tinyint(4) DEFAULT NULL,
`setorOrigem_id` int(11) DEFAULT NULL,
`unidade_id` int(11) DEFAULT NULL,
`setor_id` int(11) DEFAULT NULL,
`usuario_id` int(11) DEFAULT NULL,
`modalidadeComunicacaoJudicial_id` int(11) DEFAULT NULL,
`modalidadeRepercussao_id` int(11) DEFAULT NULL,
`especieTarefa_id` int(11) DEFAULT NULL,
`postIt` varchar(255) DEFAULT NULL,
`teor_observacao` varchar(255) DEFAULT NULL,
`comunicacaoJudicial_id` int(11) DEFAULT NULL,
`tarefa_id` int(11) DEFAULT NULL,
`mensagens` text,
`criadoPor_id` int(11) DEFAULT NULL,
`criadoEm` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=92 DEFAULT CHARSET=latin1;
How can this happen in a SELECT statement? What should I do?

This great community helped me to realize that such an error can be caused by "a mismatch in column definition (e.g. size of char fields) between the database and the dataset", and pointed me to another thread: https://stackoverflow.com/a/7029713/3718031
Possible relation with this, too: Column longtext exceeds the MaxLength limit
In my case, there are columns with "TEXT" datatype and it seems that might be the problem.
I thank deeply to all those who commented in my question and helped me to learn this.
EDIT: Since this question was voted-to-close and my problem remained, I tried to investigate a little further and made another question, I hope that one is properly exposed.

Related

Speed Up A Large Insert From Select Query With Multiple Joins

I'm trying to denormalize a few MySQL tables I have into a new table that I can use to speed up some complex queries with lots of business logic. The problem that I'm having is that there are 2.3 million records I need to add to the new table and to do that I need to pull data from several tables and do a few conversions too. Here's my query (with names changed)
INSERT INTO database_name.log_set_logs
(offload_date, vehicle, jurisdiction, baselog_path, path,
baselog_index_guid, new_location, log_set_name, index_guid)
(
select STR_TO_DATE(logset_logs.offload_date, '%Y.%m.%d') as offload_date,
logset_logs.vehicle, jurisdiction, baselog_path, path,
baselog_trees.baselog_index_guid, new_location, logset_logs.log_set_name,
logset_logs.index_guid
from
(
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(path, '/', 7), '/', -1) as offload_date,
SUBSTRING_INDEX(SUBSTRING_INDEX(path, '/', 8), '/', -1) as vehicle,
SUBSTRING_INDEX(path, '/', 9) as baselog_path, index_guid,
path, log_set_name
FROM database_name.baselog_and_amendment_guid_to_path_mappings
) logset_logs
left join database_name.log_trees baselog_trees
ON baselog_trees.original_location = logset_logs.baselog_path
left join database_name.baselog_offload_location location
ON location.baselog_index_guid = baselog_trees.baselog_index_guid);
The query itself works because I was able to run it using a filter on log_set_name however that filter's condition will only work for less than 1% of the total records because one of the values for log_set_name has 2.2 million records in it which is the majority of the records. So there is nothing else I can use to break this query up into smaller chunks from what I can see. The problem is that the query is taking too long to run on the rest of the 2.2 million records and it ends up timing out after a few hours and then the transaction is rolled back and nothing is added to the new table for the 2.2 million records; only the 0.1 million records were able to be processed and that was because I could add a filter that said where log_set_name != 'value with the 2.2 million records'.
Is there a way to make this query more performant? Am I trying to do too many joins at once and perhaps I should populate the row's columns in their own individual queries? Or is there some way I can page this type of query so that MySQL executes it in batches? I already got rid of all my indexes on the log_set_logs table because I read that those will slow down inserts. I also jacked my RDS instance up to a db.r4.4xlarge write node. I am also using MySQL Workbench so I increased all of it's timeout values to their maximums giving them all nines. All three of these steps helped and were necessary in order for me to get the 1% of the records into the new table but it still wasn't enough to get the 2.2 million records without timing out. Appreciate any insights as I'm not adept to this type of bulk insert from a select.
'CREATE TABLE `log_set_logs` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`purged` tinyint(1) NOT NULL DEFAUL,
`baselog_path` text,
`baselog_index_guid` varchar(36) DEFAULT NULL,
`new_location` text,
`offload_date` date NOT NULL,
`jurisdiction` varchar(20) DEFAULT NULL,
`vehicle` varchar(20) DEFAULT NULL,
`index_guid` varchar(36) NOT NULL,
`path` text NOT NULL,
`log_set_name` varchar(60) NOT NULL,
`protected_by_retention_condition_1` tinyint(1) NOT NULL DEFAULT ''1'',
`protected_by_retention_condition_2` tinyint(1) NOT NULL DEFAULT ''1'',
`protected_by_retention_condition_3` tinyint(1) NOT NULL DEFAULT ''1'',
`protected_by_retention_condition_4` tinyint(1) NOT NULL DEFAULT ''1'',
`general_comments_about_this_log` text,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1736707 DEFAULT CHARSET=latin1'
'CREATE TABLE `baselog_and_amendment_guid_to_path_mappings` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`path` text NOT NULL,
`index_guid` varchar(36) NOT NULL,
`log_set_name` varchar(60) NOT NULL,
PRIMARY KEY (`id`),
KEY `log_set_name_index` (`log_set_name`),
KEY `path_index` (`path`(42))
) ENGINE=InnoDB AUTO_INCREMENT=2387821 DEFAULT CHARSET=latin1'
...
'CREATE TABLE `baselog_offload_location` (
`baselog_index_guid` varchar(36) NOT NULL,
`jurisdiction` varchar(20) NOT NULL,
KEY `baselog_index` (`baselog_index_guid`),
KEY `jurisdiction` (`jurisdiction`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1'
'CREATE TABLE `log_trees` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`baselog_index_guid` varchar(36) DEFAULT NULL,
`original_location` text NOT NULL, -- This is what I have to join everything on and since it's text I cannot index it and the largest value is above 255 characters so I cannot change it to a vachar then index it either.
`new_location` text,
`distcp_returncode` int(11) DEFAULT NULL,
`distcp_job_id` text,
`distcp_stdout` text,
`distcp_stderr` text,
`validation_attempt` int(11) NOT NULL DEFAULT ''0'',
`validation_result` tinyint(1) NOT NULL DEFAULT ''0'',
`archived` tinyint(1) NOT NULL DEFAULT ''0'',
`archived_at` timestamp NULL DEFAULT NULL,
`created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`dir_exists` tinyint(1) NOT NULL DEFAULT ''0'',
`random_guid` tinyint(1) NOT NULL DEFAULT ''0'',
`offload_date` date NOT NULL,
`vehicle` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `baselog_index_guid` (`baselog_index_guid`)
) ENGINE=InnoDB AUTO_INCREMENT=1028617 DEFAULT CHARSET=latin1'
baselog_offload_location has not PRIMARY KEY; what's up?
GUIDs/UUIDs can be terribly inefficient. A partial solution is to convert them to BINARY(16) to shrink them. More details here: http://localhost/rjweb/mysql/doc.php/uuid ; (MySQL 8.0 has similar functions.)
It would probably be more efficient if you have a separate (optionally redundant) column for vehicle rather than needing to do
SUBSTRING_INDEX(SUBSTRING_INDEX(path, '/', 8), '/', -1) as vehicle
Why JOIN baselog_offload_location? Three seems to be no reference to columns in that table. If there, be sure to qualify them so we know what is where. Preferably use short aliases.
The lack of an index on baselog_index_guid may be critical to performance.
Please provide EXPLAIN SELECT ... for the SELECT in your INSERT and for the original (slow) query.
SELECT MAX(LENGTH(original_location)) FROM .. -- to see if it really is too big to index. What version of MySQL are you using? The limit increased recently.
For the above item, we can talk about having a 'hash'.
"paging the query". I call it "chunking". See http://mysql.rjweb.org/doc.php/deletebig#deleting_in_chunks . That talks about deleting, but it can be adapted to INSERT .. SELECT since you want to "chunk" the select. If you go with chunking, Javier's comment becomes moot. Your code would be chunking the selects, hence batching the inserts:
Loop:
INSERT .. SELECT .. -- of up to 1000 rows (see link)
End loop

Why does this fail on some MySQL installs and not on other MySQL/MariaDB installs

FINAL: I'm closing this question because there is no way for me to reproduce the condition and trying to find a similar occurrence has proven fruitless.
A work-around using perl is being implemented to circumvent the failure that only some mysql installs are experiencing.
UPDATE: I've had another case and verified that this query is returning 'OFF'
SELECT `VARIABLE_VALUE` FROM `information_schema`.`GLOBAL_VARIABLES` WHERE `VARIABLE_NAME` LIKE 'INNODB_STRICT_MODE'
I'm having a hard time tracking down a query issue...
This is part of an update script that I made to install new tables and import data from old ones - if they exist. This is from a procedure that is installed, and then called, by the update script:
In this snippet, the table bot_inventories is created, then a check is performed to see if the old schema table exists. If it does, the old 'base' data is then copied to the new table.
The suspect query is the 'inner' if near the bottom:
CREATE TABLE `bot_inventories` (
`inventories_index` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
`bot_id` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`slot_id` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
`item_id` INT(11) UNSIGNED NULL DEFAULT '0',
`inst_charges` TINYINT(3) UNSIGNED DEFAULT 0,
`inst_color` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`inst_no_drop` TINYINT(1) UNSIGNED NOT NULL DEFAULT '0',
`inst_custom_data` TEXT NULL,
`ornament_icon` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`ornament_id_file` INT(11) UNSIGNED NOT NULL DEFAULT '0',
`ornament_hero_model` INT(11) NOT NULL DEFAULT '0',
`augment_1` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
`augment_2` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
`augment_3` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
`augment_4` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
`augment_5` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
`augment_6` MEDIUMINT(7) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`inventories_index`),
KEY `FK_bot_inventories_1` (`bot_id`),
CONSTRAINT `FK_bot_inventories_1` FOREIGN KEY (`bot_id`) REFERENCES `bot_data` (`bot_id`)
) ENGINE=InnoDB;
IF ((SELECT COUNT(*) FROM `information_schema`.`TABLES` WHERE `TABLE_SCHEMA` = DATABASE() AND `TABLE_NAME` = 'botinventory') > 0) THEN
INSERT INTO `bot_inventories` (
`inventories_index`,
`bot_id`,
`slot_id`,
`item_id`,
`inst_charges`,
`inst_color`,
`inst_no_drop`,
`augment_1`,
`augment_2`,
`augment_3`,
`augment_4`,
`augment_5`
)
SELECT
bi.`BotInventoryID`,
bi.`BotID`,
bi.`SlotID`,
bi.`ItemID`,
bi.`charges`,
bi.`color`,
bi.`instnodrop`,
bi.`augslot1`,
bi.`augslot2`,
bi.`augslot3`,
bi.`augslot4`,
bi.`augslot5`
FROM `botinventory` bi
INNER JOIN `bot_data` bd
ON bi.`BotID` = bd.`bot_id`;
IF ((SELECT COUNT(*) FROM `information_schema`.`COLUMNS` WHERE `TABLE_SCHEMA` = DATABASE() AND `TABLE_NAME` = 'botinventory' AND `COLUMN_NAME` = 'augslot6') > 0) THEN
UPDATE `bot_inventories` bi
INNER JOIN `botinventory` bio
ON bi.`inventories_index` = bio.`BotInventoryID`
SET bi.`augment_6` = bio.`augslot6`
WHERE bi.`bot_id` = bio.`BotID`;
END IF;
RENAME TABLE `botinventory` TO `botinventory_old`;
END IF;
I have run this script myself dozens of times on both 'clean' and convertible (existing and populated botinventory table) databases with no problems.
The script executes properly on both MySQL v5.1.73 and MariaDB v10.0.22 (both win x86)
However, I've had two reported cases of failure surrounding the 'inner' if statement.
That check is in place to catch any 'customization' that may have been done by an admin and import their data.
The failed cases are reporting: "ERROR 1136 (21S01): Column count doesn't match value count at row 1"
I walked one of the admins through the manual installation of this update and found the problem to be with the 'if' query.
EDIT: It's acting like the query inside of the con check is firing off - defeating the purpose of the check itself (NULL is greater than '0'?)
(The walk-through admin is running MySQL v5.1.x as x86 on windows server 2012..the other is running MySQL v5.1.x as win (7?) x86.)
It seems to report that error when 'augslot6' does not exist - opposite behavior of what the check is in place to prevent.
I'm just not sure whether this is a syntax/methodology issue or an actual database code bug.
Searching for similar cases almost exclusively turns up results for column-entry count mis-matches, not why an if statement proves true with a false/null result...
Any suggestions?
EDIT: I am aware of what ANSI SQL code '21S01' indicates and how it could be interpreted to mean the missing augslot6 column. But, if so, why is the 'if' query proving 'true' when it should be 'false' on some systems?
EDIT: I wasn't able to perform the failing test myself as I don't have access to these systems.

comparing a varchar field to the number zero returns as if its a true match

i am looking for some work around on this problem and/or i need it to reply with an empty result or the boolean false.
using the sql statement on MySQL
`SELECT * FROM users WHERE verify = 0 LIMIT 1`
the code above returns the second row in the table.
Here is the table i used:
CREATE TABLE IF NOT EXISTS `users` (
`user_id` bigint(20) unsigned NOT NULL,
`username` varchar(30) NOT NULL,
`password` varchar(60) NOT NULL,
`email` varchar(30) NOT NULL,
`firstname` varchar(30) DEFAULT NULL,
`lastname` varchar(30) DEFAULT NULL,
`status` tinyint(1) NOT NULL DEFAULT '1',
`verify` varchar(32) NOT NULL,
`verified` bit(1) NOT NULL DEFAULT b'0'
) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=latin1;
INSERT INTO `users` VALUES(1, 'admin', '$2y$10$id6rHN6Zy8XHmCkWlAMvGO8pr3K4OD1zfFAZMaVgoGXbezY8SXcT2', 'admin#admin.com', 'Firstname', 'Lastname', 1, '21232f297a57a5a743894a0e4a801fc3', b'1');
INSERT INTO `users` VALUES(36, 'client', '$2y$10$gdtPImQhYoCIiTpTs/veW.BXsWUz6Zcxb.TY6XXQNO6uf5Q7kx99.', 'client#client.com', 'client', 'client', 1, 'cf3873cdefaefa2cc2c4f1efbba23202', b'0');
--edit, sorry did not specify want i wanted
i don't want it to return anything or maybe how do i make it that it would return false or empty result.
right now, i am using a nasty workaround by modifying the zero result and making it a text "zero" before passing it to the sql query. works but, if there is something better way that you can suggest it would be much appreciated.
I'm not sure what you expect to happen. When you write:
where verify = 0
MySQL has a conundrum. verify is a character string and 0 is an integer. They are not comparable, so MySQL converts one to the other. In this case, it will convert verify to an integer value, getting 0, and they match.
If you want a string comparison, then use:
where verify = '0'
However, that returns the same result.
If you want it to compare to the character value of 0, then perhaps you want:
where verify = '\0'

MySQL Composite Primary Key Duplicate

I have a MySQL table with a composite Primary Key.
CREATE TABLE `courses` (
`termNum` varchar(6) NOT NULL COMMENT 'Term Number',
`classNum` smallint(6) NOT NULL,
`subject` varchar(3) NOT NULL,
`courseNum` varchar(9) NOT NULL,
`classTitle` varchar(75) NOT NULL,
`numUnits` varchar(10) NOT NULL,
`dates` varchar(50) NOT NULL,
`startTime` varchar(50) NOT NULL,
`endTime` varchar(50) NOT NULL,
`location` varchar(50) NOT NULL,
`generalStudies` varchar(22) NOT NULL,
`instructor` varchar(50) NOT NULL DEFAULT 'Staff',
`seatsOpen` int(11) NOT NULL DEFAULT '0',
`dayList` varchar(50) NOT NULL,
`miss` tinyint(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`classNum`,`termNum`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
Originally I was going to just use classNum as the Primary Key, but it turns out that across terms it may actually repeat. To avoid problems, I was hoping to combine both the classNum and the termNum together into the Primary Key. Originally my queries to add data were like this:
INSERT INTO `courses` (`termNum`,`classNum`,`courseNum`,`subject`,`generalStudies`,`classTitle`,`numUnits`,`dates`,`dayList`,`startTime`,`endTime`,`location`,`instructor`,`seatsOpen`,`miss`)
VALUES ('2136','74581','101','ACC','','Accounting','3','10/21 - 12/13(C)','M W Th','6:00 PM','10:00 PM',' TBA','The Professor','50','0')
ON DUPLICATE KEY
UPDATE `courseNum` = '101',`subject` = 'ACC',`generalStudies` = '',`classTitle` = 'Accounting',`numUnits` = '3',`dates` = '10/21 - 12/13(C)',`dayList` = 'M W Th',`startTime` = '6:00 PM',`endTime` = '10:00 PM',`location` = 'TBA',`instructor` = 'The Professor',`seatsOpen` = '50',`miss` = '0';
However, after a handful of runs I noticed that it was only ever updating the same row. So I tried this:
INSERT INTO `courses` (`termNum`,`classNum`,`courseNum`,`subject`,`generalStudies`,`classTitle`,`numUnits`,`dates`,`dayList`,`startTime`,`endTime`,`location`,`instructor`,`seatsOpen`,`miss`)
VALUES ('2137','74580','101','ACC','','Accounting','3','10/21 - 12/13(C)','M W Th','6:00 PM','10:00 PM','Tempe - TBA','The Professor','50','0');
INSERT INTO `courses` (`termNum`,`classNum`,`courseNum`,`subject`,`generalStudies`,`classTitle`,`numUnits`,`dates`,`dayList`,`startTime`,`endTime`,`location`,`instructor`,`seatsOpen`,`miss`)
VALUES ('2137','90000','101','ACC','','Accounting','3','10/21 - 12/13(C)','M W Th','6:00 PM','10:00 PM','Tempe - TBA','The Professor','50','0');
And I get:
#1062 - Duplicate entry '32767-2137' for key 'PRIMARY'
Notice that I changed the classNum but not the termNum, so clearly it's not using the whole Primary Key. But what really confuses me is if I instead change the termNum and leave the classNum the same, it works perfectly. I've tried switching the order of the fields in the PRIMARY KEY () line, but it's the same thing.
I've searched around and there doesn't seem to be anything obviously wrong. I tried rebuilding the tables, but no change there.
You are inserting value of 74581 on classNum but the actual value that will be inserted is 32767.
The reason is because you are using smallint(6) datatype on column classNum which has the maximum value of 32767. Try changing the data type that can hold larger range of number, ex. INT UNSIGNED
classNum INT UNSIGNED NOT NULL,
for more information about Numeric Datatype Range, please see the link below
Numeric Type Overview
other link...

Error Delphi / MySQL / Parameters

Well, the situation is: I have 1 TComboBox called cboTipDocIden and 1 TEdit called txtDocIdenSolic.
The values of cboTipDocIden are: "1.DNI","2.RUC".
The component TUniQuery is called q_DetSolicitante.
The SQL Sentence target is:
SELECT oper_solicitante.id_solicitante, oper_solicitante.ape_pat, oper_solicitante.ape_mat,
oper_solicitante.nombre, oper_solicitante.direcc_idtipcalle, oper_solicitante.direcc_nombrecalle,
oper_solicitante.direcc_nro, oper_solicitante.idvinculo_fk
FROM oper_solicitante
WHERE oper_solicitante.tipDocIden = :TipDocIden AND
oper_solicitante.nroDocIden = :NroDocIden
The SQL is executed on OnExit event of txtDocIdenSolic, here the code:
procedure TForm1.txtDocIdenSolicExit(Sender: TObject);
var
TipDocIden, NroDocIden:string;
begin
if(length(txtDocIdenSolic.Text)>0) then
begin
TipDocIden:=chr(39)+copy(cboTipDocIden.Text,1,1)+chr(39);
NroDocIden:=chr(39)+trim(txtDocIdenSolic.Text)+chr(39);
q_DetSolicitante.Close;
q_DetSolicitante.Params[0].AsString:=TipDocIden;
q_DetSolicitante.Params[1].AsString:=NroDocIden;
q_DetSolicitante.Open;
if(length(q_DetSolicitante.FieldByName('id_solicitante').AsString)=0) then
begin
stbar.Panels[0].text:='Nuevo Solicitante...';
txtApePat.SetFocus;
end
else
begin
stbar.Panels[0].Text:='Solicitante Reiterativo...';
txtApePat.Text:=q_DetSolicitante.FieldByName('ape_pat').AsString;
txtApeMat.Text:=q_DetSolicitante.FieldByName('ape_mat').AsString;
txtNombre.Text:=q_DetSolicitante.FieldByName('nombre').AsString;
end;
end
else
msg1.Execute;
end;
Finally, the table structure is:
CREATE TABLE `oper_solicitante` (
`id_solicitante` int(11) NOT NULL,
`tipDocIden` char(1) NOT NULL,
`nroDocIden` varchar(11) NOT NULL,
`ape_pat` varchar(50) NOT NULL,
`ape_mat` varchar(50) NOT NULL,
`nombre` varchar(50) NOT NULL,
`direcc_idtipcalle` int(11) NOT NULL,
`direcc_nombrecalle` varchar(80) NOT NULL,
`direcc_nro` varchar(15) NOT NULL,
`idvinculo_fk` int(11) NOT NULL,
PRIMARY KEY (`id_solicitante`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Well, the SQL returns zero rows inside Delphi but when i change the parameters for literal values the SQL works.
Thanks for your useful help.
Remove the chr(39) characters around your parameter values. Using Params[].AsString allows the database driver to properly quote them, and you're adding (doubling) them and thus causing the query to fail.
TipDocIden:= copy(cboTipDocIden.Text,1,1);
NroDocIden:= trim(txtDocIdenSolic.Text);
q_DetSolicitante.Close;
q_DetSolicitante.Params[0].AsString := TipDocIden;
q_DetSolicitante.Params[1].AsString := NroDocIden;
q_DetSolicitante.Open;