BUG - v5.2.040 - RESOLVIDO

Bugs
#1

Pessoal,

Após atualizar para a v5.2.040, uma das minhas aplicações (não tive coragem de gerar as demais) começou a apresentar esse erro ao executá-la:

Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in /var/www/scriptcase/app/o2s/AN001FRM/AN001FRM_apl.php on line 1555

Após ver o código, o scriptcase começo a colocar uma contra-barra no critério relativo a minha variável de sessão. Assim:

$nm_comando = "SELECT concat(' - ', BADENOCO) FROM bacolabt WHERE AANUUSUA_FK = \" . $_SESSION['nu_usuario'] . \" AND BANUCOLA = $this->ancoincl";

$nm_comando = "SELECT ADDOBJET FROM adobjett WHERE AANUUSUA_FK = \" . $_SESSION['nu_usuario'] . \" AND ADNUOBJE = $this->adnuobje_fk";

E essa seria a atualização que antecederia a V6. E agora? Terei que editar na mão para tirar essas contra-barras ou terei que esperar a nova versão para talvez gerar corretamente as aplicações? Por essa eu não esperava!!!

#2

olá

a meu ver, por alto, diria que a sentença está errada. Me parece estar faltando aspas ou apostrofes.

O correto não seria assim:

AANUUSUA_FK = “” . $_SESSION[‘nu_usuario’] . “” AND BANUCOLA = ‘".$this->ancoincl."’"

ou assim

AANUUSUA_FK = ‘" . $_SESSION[‘nu_usuario’] . "’ AND BANUCOLA = ‘".$this->ancoincl."’"

?

abraços

#3

tb acho !

#4

Pessoal,

Esse é o grande problema, porque após essa atualização o SC começou a colocar essas barras. Elas não foram declaradas na query e tampouco fazem parte do SQL definido na aplicação.

Os SQL foram reescritos várias vezes, a variável de sessão em questão foi alterada para somente GET/POST, mas em todas as tentativas, sempre gerava com essa maldita contra-barra.

Procurei por algum parâmetro novo ou diferente na Administração, Projeto e até Conexão com BD, mas nada encontrei que pudesse reverter isso.

Meu projeto parou! Prejuízo!!

#5

as contras barras são necessárias pois você colocou aspas duplas na instrução, e ao gerar o código php o sc precisa delimitar isso como uma constante alfnumérica (string), e que provavelmente usa as aspas duplas para delimitar, gerando uma inconsistência com seu código sql inserido. Utilize sempre aspas simples no código.

Dicas quando for usar sc_lookup:

  • jogue a instrução sempre numa variável php antes. (sc_lookup(rs,$_sql));
    -evite aspas duplas em instruções sql
    -mova variáveis em sessão, globais, campos para variáveis locais php e as utilize sempre concatenando constantes com variáveis
    -nas comparações com campos {} ou variáveis do sc sempre de espaços entre os operadores e esses campos, o SC falha em algumas situações (IF $valor == {campo} && $valor <> [variavel])
  • Em instruções sql se a coluna sql for um inteiro ou número evite delimitar campos apos a comparação ( where id = “.$_id.” …) pois alguns bancos não aceitam comparar inteiro com string, mas garanta que o outro lado da comparação tenha um valor numérico.
#6

Pessoal,

O mais estranho é que não mudei o SQL original. É o mesmo implementado desde quando o projeto estava no SC4. Simplesmente gerei a transação na 5.2.040 após mudar uma ligação. Daí todos os SQLs do formulário eram gerados pelo SC com essa \

#7

Pessoal,

Confirmada minha desconfiança. Vejam a diferença entre o mesmo SQL gerado pelo SC na v5.2.039 e v5.2.040

v5.2.039

      if (!$validate)^M
      {^M
          $Salva_opc = $this->nmgp_opcao;^M
          $this->nmgp_opcao = "lookup_rpc";^M
          $this->nm_converte_datas();^M
          $this->nmgp_opcao = $Salva_opc;^M
      }^M
      if (in_array(strtolower($this->Ini->nm_tpbanco), $this->Ini->nm_bases_ibase))^M
      { ^M
          $GLOBALS["NM_ERRO_IBASE"] = 1;  ^M
      } ^M
      $nm_comando = "SELECT ADDOBJET
FROM adobjett
WHERE
  AANUUSUA_FK=" . $_SESSION['nu_usuario'] . " AND
  ADNUOBJE=$this->adnuobje_fk"; ^M
      if ($this->adnuobje_fk == "")^M
      { ^M
          $conteudo = ""; ^M
          if (!$validate)^M
          {^M
              $this->nm_formatar_campos();^M

v5.2.040

      if (!$validate)^M
      {^M
          $Salva_opc = $this->nmgp_opcao;^M
          $this->nmgp_opcao = "lookup_rpc";^M
          $this->nm_converte_datas();^M
          $this->nmgp_opcao = $Salva_opc;^M
      }^M
      if (in_array(strtolower($this->Ini->nm_tpbanco), $this->Ini->nm_bases_ibase))^M
      { ^M
          $GLOBALS["NM_ERRO_IBASE"] = 1;  ^M
      } ^M
      $nm_comando = "SELECT ADDOBJET
FROM adobjett
WHERE
  AANUUSUA_FK = \" . $_SESSION['nu_usuario'] . \" and
  ADNUOBJE = $this->adnuobje_fk"; ^M
      if ($this->adnuobje_fk == "")^M
      { ^M
          $conteudo = ""; ^M
          if (!$validate)^M
          {^M
              $this->nm_formatar_campos();^M

Solução. Regredir para v5.2.039.

#8

Foi exatamente o que eu disse, o código na 39 é que está formatado de forma inconsistente

#9

Haroldo,

Mas o MySQL só executa o SQL gerado pelo SC na 39, sem as barras. Esse é um trecho de código de lookup de campo após geração da aplicação (código php criado pelo SC) e o select usado é o mesmo em ambas as versões. Sem tirar nem por.

O SQL original é exatamente assim para o lookup do campo adnuobje_fk da aplicação:

SELECT ADDOBJET
FROM adobjett
WHERE
  AANUUSUA_FK = [nu_usuario] AND
  ADNUOBJE = {adnuobje_fk}

Obs: Ambos [nu_usuario] e {adnuobje_fk} são numéricos.

Então, em todos os SQLs da aplicação na 40 foram incluídas as [b][/b] no critério AANUUSUA_FK = [nu_usuario], mas isso não acontece na 39.

#10

troque pelas aspas simples, vai funcionar.