Início / dba / Perguntas / 48501
Accepted
Jacobm001
Asked: 2013-08-22 10:35:56 +0800 CST

Erro de Função do MySQL

  • 772

Em um banco de dados herdado, tenho duas tabelas de interesse atual recordse logins. loginme diz a localização do usuário e onde e quando seu login ocorreu (horários de entrada e saída incluídos).

A parte divertida é que não há marca de correlação entre a sessão de login e os aplicativos executados. Para resolver o problema, estou criando uma nova tabela login_appse tentando usar uma função para combinar as duas tabelas.

Até agora eu tenho:

drop function if exists ltop;
delimiter $$

create function ltop(id int, u varchar(10), s datetime, e datetime)
    returns text
    language sql
begin
    declare pid varchar(40);
    declare pname varchar(63);
    declare my_return varchar(100);
    declare cur1 cursor for (select usageProgramID 
                                from records 
                                where usageUser=u
                                    and usageWhen>=s 
                                    and usageWhen<=e
                                    and usageProgramID!="");
    open cur1;
    read_loop: loop
        fetch cur1 into pid;
        set pname = (select programName from Programs where programID=pid);
        insert into login_apps(`sid`, `programName`) values(id, pname);
    end loop read_loop;

    close cur1;

    return "finished";
end;$$
delimiter ;

Ele entra no sistema sem problemas e a inserção está funcionando conforme o esperado em um teste. O problema que estou apresentando é que, quando é executado como:

select ltop("265548", "user", "2013-02-21 13:54:27", "2013-02-21 14:32:18");

Eu recebo o erro:

ERROR 1329 (02000): No data - zero rows fetched, selected, or processed

Os dados a serem retornados não deveriam estar "concluídos"?

Em segundo lugar, não tenho muita certeza de qual seria a melhor maneira de executar isso em todos os valores de loginsquaisquer ponteiros para seguir essa rota.

mysql mysql-5.1

1 respostas

  1. Best Answer
    ERROR 1329 (02000): No data - zero rows fetched, selected, or processed

    Esse erro não é sobre o seu RETURN; é isso:

    fetch cur1 into pid;

    Quando o cursor fica sem dados, esse erro é lançado. Isso pode ocorrer porque a SELECTconsulta declarada no cursor não encontrou nenhuma linha ou porque encontrou linhas, mas conforme você iterava por ela, você leu além da última linha. Se nada acontecesse quando o cursor ficasse sem dados, como você escaparia read_loop?

    Você precisa interceptar o erro com um manipulador , o que impedirá que a execução do procedimento seja encerrada e defina uma variável que possa ser usada para interromper o loop.

    No topo, com as outras variáveis:

    DECLARE done TINYINT DEFAULT 0;

    Então, depois de declarar, mas antes de abrir o cursor:

    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

    Dentro do seu loop:

    fetch cur1 into pid;
IF done = 1 THEN LEAVE read_loop; END IF;

    Isso deve resolver seu problema imediato.

    Outras observações:

    Sua função modifica o banco de dados, portanto, no topo, você deve ter isto:

    returns text
MODIFIES SQL DATA
language sql

    ...embora, realmente, isso seria mais apropriadamente escrito como um procedimento armazenado em vez de uma função. O MySQL suporta funções armazenadas não determinísticas que modificam o banco de dados, você pode ter problemas potenciais com o log binário usado para recuperação pontual ou replicação.

    Para processar todos os dados em vez de um valor de cada vez, você pode usar cursores aninhados - o cursor externo buscando quaisquer dados que você está alimentando nesta função e o cursor interno - dentro de um bloco BEGIN/ adicional fazendo a lógica que você ENDobtivemos acima com valores buscados no cursor externo. Isso requer a redefinição do donevalor de volta para 0 após cada iteração do bloco interno para que o outro bloco não pare prematuramente.

    A subconsulta interna é desnecessária, pois o cursor pode ser declarado com...

    SELECT p.programName
  FROM records r JOIN Programs p ON p.programID = r.usageProgramID
 WHERE ...

    ...mas, na verdade, toda essa função parece ser desnecessária .

    Em SQL, normalmente é melhor dizer ao banco de dados o que precisa ser feito ("declarativo"), em vez de como fazê-lo ("procedural").

    Pensar de maneira muito processual é um antipadrão SQL .

    Não sei os nomes das colunas na tabela 'login', então você precisará corrigi-los, mas considere a seguinte consulta. Tanto quanto eu posso dizer, ele faz exatamente o que a função faz, para todos os logins e todos os registros correspondentes.

    INSERT INTO login_apps(`sid`, `programName`)
SELECT l.session_id, p.programName
  FROM logins l
  JOIN records r ON r.usageUser = l.user_name 
                AND r.usageWhen >= l.start_time 
                AND r.usageWhen <= l.end_time
                AND r.usageProgramID != ""
  JOIN Programs p ON p.programID = r.usageProgramID;

    Feito.

    Para manutenção futura da tabela "login_apps", um gatilho na tabela "records" pode procurar o login relacionado e gravar as novas entradas em "login_apps" toda vez que "records" tiver uma inserção ou atualização... ou quando o o tempo de parada é registrado na tabela "login", um gatilho de atualização pode ler "registros" e inserir em "login_apps".

    Pensamento final, provavelmente seria um design melhor se você armazenasse o ID do programa em vez do nome do programa na tabela login_apps ... a menos que a tabela "records" realmente tenha uma chave primária auto_increment, caso em que esse seria o valor que você deveria realmente armazene em login_apps.

    • 2

relate perguntas