O componente chamado TZQuery presente na paleta do Zeos \u00e9 basicamente para executar queries que retornam valores para um TDataset ou ResultSet como preferir chamar. Da\u00ed componentes que contenham a propriedade Datasource e Dataset tais como DBGrid, DBEdit, DBNavigator,… se alimentam dele.<\/p>\n\n\n\n
Uma capacidade muto interessante do TZQuery \u00e9 que o mesmo \u00e9 capaz de fazer o streamming ou pagina\u00e7\u00e3o de dados conforme o uso, isto \u00e9 importante porque ao trazer uma quantidade muito grande de dados para esta\u00e7\u00e3o cliente, os recursos do cliente podem ser exauridos e talvez parar de responder. Mas usando o recurso de pagina\u00e7\u00e3o, o cliente requisita os registros que precisar\u00e1 ver sob demanda. Imagine um DBGrid e imagine uma pesquisa contendo mil registros, por\u00e9m o DBGrid mostra apenas 50 registros por vez, isto significar\u00e1 que a mesmo que voc\u00ea precisar\u00e1 ir para o registro #51 para a query v\u00e1 at\u00e9 o servido e pegue mais 50 registros. Claro que essa habilidade \u00e9 configur\u00e1vel atrav\u00e9s de m\u00e9todos como FetchRow ou FetchALL.<\/p>\n\n\n\n
H\u00e1 um componente muito similar chamado ZReadOnlyQuery, a \u00fanica diferen\u00e7a \u00e9 que n\u00e3o tem como us\u00e1-la para modificar os dados. Nem mesmo suporte a TUpdateSQL ela possui. Por n\u00e3o ter como us\u00e1-la para modificar o banco, pense nela como um componente mais leve para ser usaodo em consultas, relat\u00f3rios, exporta\u00e7\u00e3o de dados e afins.<\/p>\n\n\n\n
Vamos a uma explica\u00e7\u00e3o sobre cada propriedade do componente ZQuery: <\/p>\n\n\n\n
Active<\/h2>\n\n\n\n
Tipo “true” ou “false”. Quando passa de falso para verdadeiro, a senten\u00e7a SQL que estiver na propriedade “SQL” \u00e9 executada e se tudo ocorrer bem ent\u00e3o Active passa a ser “true”, se falhar ent\u00e3o permanece em “false”. Algo sugerido antes de passar de false para true \u00e9 testar se o mesmo n\u00e3o esta ativo e se o estiver ent\u00e3o fech\u00e1-lo, al\u00e9m de liberar mem\u00f3ria, as outras propriedades n\u00e3o ser\u00e3o influenciadas por mudan\u00e7as com o dataset aberto, como se faz isso? simples:<\/p>\n\n\n\n
if ZQuery1.Active then\n ZQuery1.Close;<\/pre><\/div>\n\n\n\n
AutoCalcFields<\/h2>\n\n\n\n
Tipo “true” ou “false”. Quando verdadeiro indica que quando o Dataset for aberto haver\u00e1 processamento de TFields definidos como “calculated” (“calculado” daqui em diante) no evento OnCalcFields. O calculo ocorre tamb\u00e9m quando o foco do dataset muda para o campo “calculado”. Se falso, tais TFields mesmo que marcados como “calculado” n\u00e3o ser\u00e3o processados:<\/p>\n\n\n\nCampos Calculated existem apenas na aplica\u00e7\u00e3o e s\u00e3o calculados no evento OnCalcFields<\/figcaption><\/figure>\n\n\n\n
CachedUpdates<\/h2>\n\n\n\n
Tipo “true” ou “false”. Os dados ser\u00e3o armazenados localmente pelo programa e n\u00e3o ser\u00e3o enviados para o banco de dados at\u00e9 que o m\u00e9todo ApplyUpdates<\/strong> seja invocado junto com o CommitUpdates<\/strong> para confirmar as opera\u00e7\u00f5es ou CancelUpdates<\/strong> para desfaz\u00ea-las.<\/p>\n\n\n\n
Connection<\/h2>\n\n\n\n
Tipo ZConnection. Toda query precisa estar assinalada a uma conex\u00e3o, no caso do componente Zeos, uma conex\u00e3o \u00e9 tamb\u00e9m uma TIL(Transaction Isolation Layer). A partir do Zeos8 h\u00e1 um componente ZTransaction<\/strong> que corrige essa dificuldade e podemos ter uma query assinalada a uma conex\u00e3o e um tipo de TIL em particular.<\/p>\n\n\n\n
DataSource<\/h2>\n\n\n\n
Tipo TDatasource. Similar as propriedades LinkedFields, MasterFields e MasterSource para formul\u00e1rios que exibem dados do tipo Mestre\/Detalhe, mas com uma \u00fanica diferen\u00e7a, cria dinamicamente a query detalhe enquanto navega-se no datasource Mestre(apenas Datasource neste contexto). Por exemplo:<\/p>\n\n\n\n
select * from tdetalhe where campo1_tdetalhe =:campo2_tmestre<\/pre><\/div>\n\n\n\n
\u00c9 mais vantajoso do que usar LinkedFields, MasterFields e MasterSource porque estes funcionam apenas quando os dados j\u00e1 foram trazidos localmente e est\u00e3o com o dataset ativo, enquanto usando a propriedade Datasource, uma nova query ser\u00e1 gerada toda vez que a posi\u00e7\u00e3o do cursor no datasource(mestre) se alterar.<\/p>\n\n\n\n
FetchRow<\/h2>\n\n\n\n
Tipo Inteiro. Determina a quantidade de registros que ser\u00e3o trazidos por vez para o lado clente, isso \u00e9 basicamente uma pagina\u00e7\u00e3o de dados autom\u00e1tica. Por exemplo, se for informado 50<\/strong> ent\u00e3o apenas 50 registros ser\u00e3o trazidos para o lado cliente por vez. Isso minimiza o impacto que haveria se trouxesse todos os registros de uma \u00fanica vez. Se usar zero<\/strong>, o sistema trar\u00e1 todos os registros e n\u00e3o haver\u00e1 pagina\u00e7\u00e3o e ser\u00e1 uma consulta mais lenta e consumindo mais recursos. Se o valor for -1<\/strong>, o sistema arbitrar\u00e1 uma quantidade que julgar suficiente conforme a \u00e1rea dispon\u00edvel para exibi-las.<\/p>\n\n\n\n
Quando pagina\u00e7\u00e3o de dados est\u00e1 envolvida podemos usar o m\u00e9todo FetchALL para trazer todos os registros para a esta\u00e7\u00e3o cliente. Alguns usam FetchALL para poder usar a propriedade RecordCount que retorna a quantidade de registros, por\u00e9m essa n\u00e3o \u00e9 uma boa ideia porque todos os registros ser\u00e3o lidos, uma tarefa muito pesada para apenas saber quantos registros h\u00e1. O ideal \u00e9 um SELECT COUNT(*) por cima da query adjacente para obter quantidade de registros, imagine a query:<\/p>\n\n\n\n
Select * from clientes where razao_social like "a%"<\/pre><\/div>\n\n\n\n
Como saber quantos registros a query acima retornou sem ter de usar um FetchALL? Usamos uma query derivativa, veja:<\/p>\n\n\n\n
Select count(*) from (\n Select * from clientes where razao_social like "a%"\n)<\/pre><\/div>\n\n\n\n
Assim ser\u00e1 perfeitamente poss\u00edvel criar uma fun\u00e7\u00e3o gen\u00e9rica e reutiliz\u00e1-la sobre qualquer query. E se voc\u00ea se preocupou que algum campo ser\u00e1 lido por causa da men\u00e7\u00e3o \u00e0s colunas, o gerenciador de banco de dados tem intelig\u00eancia suficiente para entender que nossa a\u00e7\u00e3o \u00e9 saber a quantidade de registro e n\u00e3o os dados em si.<\/p>\n\n\n\n
Filter e Filtered<\/h2>\n\n\n\n
Filter<\/strong> \u00e9 do tipo String, enquanto Filtered<\/strong> \u00e9 “true” ou “false”. Filter \u00e9 basicamente uma express\u00e3o que determinar\u00e1 os resultados que estar\u00e3o vis\u00edveis dentro dum TDataset quando Filtered=true<\/strong>. Se estiver paginando dados, todos os dados ser\u00e3o resgatados para a aplica\u00e7\u00e3o do filtro. Exemplo de filtros s\u00e3o “nome like ‘*santos*'” ou “cancelado=true”.<\/p>\n\n\n\n
Importante<\/strong>: Se estiver usando pagina\u00e7\u00e3o de dados, ao usar Filter e Filtered, todos os registros ser\u00e3o trazidos para o lado cliente, por isso, se puder usar WHERE em seu select ser\u00e1 mais perform\u00e1tico. Use Filtros quando todos os registros de que precisa j\u00e1 est\u00e3o no lado cliente, \u00e9 o caso de quando populamos uma tabela tempor\u00e1ria para ser exibida em tela e depois processada.<\/p>\n\n\n\n
IndexFieldNames<\/h2>\n\n\n\n
Nomes dos campos pelo qual manter\u00e1 ordena\u00e7\u00e3o. Os nomes podem estar separados por ponto-e-virgula, por exemplo:<\/p>\n\n\n\n
nome;escolaridade<\/code><\/pre>\n\n\n\n
Tamb\u00e9m \u00e9 poss\u00edvel usar os sufixos “asc” ou “desc” para que a ordena\u00e7\u00e3o seja ascendente ou descendente:<\/p>\n\n\n\n
nome desc<\/code><\/pre>\n\n\n\n
\u00c9 bom usar essa propriedade com um \u00edndice atrelado a tabela, caso contr\u00e1rio, os dados ter\u00e3o de ser ordenados em tempo de execu\u00e7\u00e3o e isso diminuir\u00e1 significativamente a performance. Um exemplo pr\u00e1tico de us\u00e1-lo \u00e9 no evento onTilteClick de um DBGrid, veja o exemplo:<\/p>\n\n\n\n
As vezes tamb\u00e9m \u00e9 necess\u00e1rio indicar que o t\u00edtulo da coluna \u00e9 clic\u00e1vel para ordena\u00e7\u00e3o, uma maneira de fazer isso \u00e9 mudar a aparencia do cursor quando passa o ponteiro do mouse por cima delas, isso pode ser conseguido usando o evento OnMouseMove do DBGrid, veja o exemplo:<\/p>\n\n\n\n
Importante<\/strong>: Se estiver usando pagina\u00e7\u00e3o de dados, ao usar IndexFieldNames, todos os registros ser\u00e3o trazidos para o lado cliente.<\/p>\n\n\n\n
LinkedFields, MasterFields e MasterSource<\/h2>\n\n\n\n
Geralmente s\u00e3o usados em conjunto para exibi\u00e7\u00e3o de dados do tipo Mestre<->Detalhe. Por exemplo, a tabela clientes e tabela pedidos, voc\u00ea indica em pedidos que a MasterSource ser\u00e1 a tabela de clientes, MasterFields ser\u00e1 ID_CLIENTE que liga as duas tabelas e LinkedFields \u00e9 automaticamente ajustada para dizer que ID_CLIENTE de uma tabela refere-se ID_CLIENTE de outra tabela. Geralmente usamos nomes de campos iguais em ambas, mas se a modelagem for diferente, n\u00e3o h\u00e1 problemas desde que o nomes dos campos sejam apontados corretamente em LinkedFields.<\/p>\n\n\n\n
Options<\/h2>\n\n\n\n
Trata-se de um set de possibilidades, Sendo:<\/p>\n\n\n\n
doAlignMaxRequiredWideStringFieldSize<\/strong>: o alinhamento usar\u00e1 o tamanho m\u00e1ximo da defini\u00e7\u00e3o do campo como referencia<\/li>
doAlwaysDetailResync<\/strong>: Alguns bancos tem numero de linhas virtuais, e as vezes programadores usam essas linhas como referencias em visualiza\u00e7\u00f5es mestre\/detalhe. Aqui temos a possibilidade de alterar o rowno <\/em>na tabela mestre e recarregar totalmente as tabelas de detalhes.<\/li>
doCachedLobs<\/strong>: Alguns drivers, como o Firebird, suportam o carregamento de LOBs (BLOBs e CLOBs) sob demanda. Esses drivers geralmente s\u00f3 carregam LOBs do servidor quando s\u00e3o lidos e os fecham se n\u00e3o forem mais necess\u00e1rios. A configura\u00e7\u00e3o doCachedLobs armazenar\u00e1 em cache esses BLOBs e CLOBs no lado do cliente. Drivers que n\u00e3o suportam o carregamento atrasado de LOBs ignorar\u00e3o essa op\u00e7\u00e3o e sempre armazenar\u00e3o em cache LOBs no lado do cliente.<\/li>
doCalcDefaults<\/strong>: Deve ser ativado por padr\u00e3o. Os Zeos tentar\u00e1 carregar e manipular os valores padr\u00e3o que sua defini\u00e7\u00e3o de tabela cont\u00e9m para os campos. Se desligado, a aus\u00eancia de um valor poder\u00e1 gerar uma exce\u00e7\u00e3o.<\/li>
doDontSortOnPost<\/strong>: N\u00e3o mude a ordem das linhas exibidas quando fizer o “Post”.<\/li>
doNoAlignDisplayWidth<\/strong>: N\u00e3o alinhe pela largura do titulo do campo(DisplayWidth)<\/li>
doOemTranslate<\/strong>: Usar ou n\u00e3o convers\u00e3o para OEM.<\/li>
doPreferPrepared<\/strong>: Autopreparar ou n\u00e3o as queries. Se as queries tem par\u00e2metros, mas foi esquecida a prepara\u00e7\u00e3o, a partir da segunda execu\u00e7\u00e3o faz o preparo automaticamente.<\/li>
doSmartOpen<\/strong>: Normalmente TZQuery e TZReadOnlyQuery ir\u00e3o gerar uma exce\u00e7\u00e3o se voc\u00ea tentar usar o m\u00e9todo Open em instru\u00e7\u00f5es que n\u00e3o retornam dados. Isso pode acontecer ao usar INSERT, UPDATE e DELETE. Com essa op\u00e7\u00e3o definida, o conjunto de dados n\u00e3o gerar\u00e1 uma exce\u00e7\u00e3o, mas abrir\u00e1 um conjunto de dados vazio com zero linhas e zero colunas.<\/li>
doUpdateMasterFirst<\/strong>: Isso significa que todas as tabelas de detalhes s\u00e3o registradas no mestre e vice-versa. Eu determino qual \u00e9 o mestre e esta tabela \u00e9 atualizada primeiro. Em seguida, todas as tabelas de detalhes ser\u00e3o atualizadas. Isso \u00e9 muito \u00fatil se voc\u00ea tiver restri\u00e7\u00f5es.<\/li><\/ul>\n\n\n\n
ParamChar<\/h2>\n\n\n\n
Parametros s\u00e3o aquelas ocorr\u00eancias de variaveis dinamicas precedidas geralmente por “:”, exemplo:<\/p>\n\n\n\n
select * from clientes where id_cliente=:p_id_cliente<\/pre><\/div>\n\n\n\n
Pois bem, :p_id_cliente<\/strong> \u00e9 um par\u00e2metro e os “:”<\/strong> \u00e9 o ParamChar. Um problema a ser evitado \u00e9 achar que par\u00e2metros s\u00e3o como macro-substitui\u00e7\u00f5es, uma especie de Search\/Replace dentro de queries, pois n\u00e3o s\u00e3o. Par\u00e2metros s\u00e3o formas de identificar para o servidor SGBD a possibilidade de repeti\u00e7\u00e3o de uma mesma senten\u00e7a SQL, da\u00ed ele passar\u00e1 a se lembrar do calculo de menor custo para a opera\u00e7\u00e3o e n\u00e3o precisar\u00e1 recalcul\u00e1-lo toda vez. Um ponto importante \u00e9 que uma vez “preparada” qualquer query de mesma assinatura se beneficiar\u00e1 do calculo previamente realizado para qualquer usu\u00e1rio que estiver conectado e n\u00e3o apenas quem fez a primeira prepara\u00e7\u00e3o, deveras, mesmo que quem preparou da primeira vez tenha sua conex\u00e3o terminada a query ainda ser\u00e1 mantida pelo tempo que o servidor considerar necess\u00e1rio.<\/p>\n\n\n\n
A propriedade ParamChar existe porque nem sempre \u00e9 desej\u00e1vel que par\u00e2metros sejam identificados por “:”<\/strong>, por que n\u00e3o? Porque podem haver senten\u00e7as onde “:”<\/strong> deve ser tratado de outro jeito, por exemplo, no FirebirdSQL dependendo de como voc\u00ea cria um psql “:etiqueta” pode ser um par\u00e2metro ou uma referencia a uma vari\u00e1vel local e da\u00ed temos uma ambiguidade, ex:<\/p>\n\n\n\n
declare variable id_cliente int;\nbegin\n (...)\n for select id_cliente from clientes where id_cliente=1001 into :id_cliente<\/strong>;<\/code><\/pre>\n\n\n\n
No exemplo acima, id_cliente \u00e9 um campo da tabela, contudo :id_cliente \u00e9 excepcionalmente uma vari\u00e1vel local de mesmo nome. Situa\u00e7\u00f5es assim acontecem em banco de dados que tenham suporte a psql e note que n\u00e3o s\u00e3o par\u00e2metros, mas o Zeos n\u00e3o saber\u00e1 como distinguir, a menos que o psql seja escrito de uma maneira diferente ou que deixe de usar “:” como indicador de par\u00e2metro para usar outro caractere diferente.<\/p>\n\n\n\n
No FirebirdSQL, em algumas situa\u00e7\u00f5es como a descrita acima \u00e9 necess\u00e1rio trocar ParamChar, ex:<\/p>\n\n\n\n
execute block(p_id_cliente int=~p_id_cliente, p_cancelar boolean=~p_cancelar) returns (error_msg varchar(255));\nbegin\n error_msg='';\n if (:p_id_cliente<=0) then\n error_msg='Codigo de cliente invalido';\n (...) \n suspend;\nend<\/pre><\/div>\n\n\n\n
Note que a assinatura (onde est\u00e3o os par\u00e2metros de entrada e sa\u00edda) cont\u00eam ~p_id_cliente e ~p_cancelar, por que fiz assim? Para que pud\u00eassemos indicar “~” como ParamChar e o Zeos entender que eles s\u00e3o os par\u00e2metros e o :p_id_cliente mais abaixo fosse interpretado como parte do psql e o Zeos n\u00e3o toque nele. <\/p>\n\n\n\n
IMPORTANTE:<\/strong> Evite o “?”(ponto de interroga\u00e7\u00e3o) como ParamChar, pois ele \u00e9 reservado para outra coisa e n\u00e3o funcionaria adequadamente.<\/p>\n\n\n\n
ParamCheck<\/h2>\n\n\n\n
Tipo “true” ou “false”. Se “true” a lista de par\u00e2metros \u00e9 esvaziada e os parametros s\u00e3o populados com base na SQL informada no momento em que o m\u00e9todo ParamByName ou Params \u00e9 invocado. Se o valor for “false” a lista n\u00e3o ser\u00e1 conferida com o SQL e portanto a lista de par\u00e2metros estar\u00e1 sempre intacta, mas voc\u00ea ter\u00e1 de fornecer os par\u00e2metros(propriedade Params) manualmente.<\/p>\n\n\n\n
Params<\/h2>\n\n\n\n
Tipo Lista. Em associa\u00e7\u00e3o com as propriedades ParamCheck e SQL, mant\u00eam uma lista de parametros quie poder\u00e3o ser usados. Existem os m\u00e9todos .ParamByName(‘p_nome’) e Params[n] que permitem acessar o par\u00e2metro e seu valor. Ex:<\/p>\n\n\n\n
ShowMessage('Quantidade de parametros: '+IntToStr(zqupdate.Params.Count)); \nzquery1.parambyname('p_id_cliente').AsInteger:=col_ID_CLIENTE;\nzquery1.parambyname('p_NOME_ALTERNATIVO').AsString:=col_NOME_ALTERNATIVO;\nzquery1.parambyname('p_END_CIDADE').AsString:=col_END_CIDADE;\nzquery1.parambyname('p_END_UF').AsString:=col_END_UF;\nzquery1.parambyname('p_STATUS').AsString:=col_STATUS;\nzquery1.Params[0].AsInteger:=col_ID_CLIENTE;\nzquery1.Params[1].AsString:=col_NOME_ALTERNATIVO;\nzquery1.Params[2].AsString:=col_END_CIDADE;\nzquery1.Params[3].AsString:=col_END_UF;\nzquery1.Params[4].AsString:=col_STATUS; <\/pre><\/div>\n\n\n\n
IMPORTANTE<\/strong>: Acessar ou mudar par\u00e2metros pelo seu \u00edndice \u00e9 bem mais r\u00e1pido, mas s\u00f3 fa\u00e7a isso se estiver numa opera\u00e7\u00e3o de lote muito demorada porque acessar seus valores usando o nome do par\u00e2metro tem a vantagem de evitar erros como mudar a ordem dos par\u00e2metros.<\/p>\n\n\n\n
Properties<\/h2>\n\n\n\n
Uma lista de par\u00e2metros para estabelecer comportamentos com a base de dados, usar properties aqui significa que os comportamentos que eu desejo \u00e9 apenas para a query e n\u00e3o para a conex\u00e3o inteira. Por exemplo, pode usar properties para estabelecer um timeout para sua query. Por exemplo, no firebird podemos:<\/p>\n\n\n\n
SET STATEMENT TIMEOUT 30 SECONDS;\nUPDATE CLIENTES SET STATUS='C' WHERE (...)<\/pre><\/div>\n\n\n\n
Contudo, o comando SET poderia ser suprimido se eu acrescentasse como par\u00e2metro:<\/p>\n\n\n\n
isc_req_stmt_timeout=30<\/code><\/pre>\n\n\n\n
Porque ter uma propriedade assim j\u00e1 que podemos faz\u00ea-lo numa mesma senten\u00e7a? Porque alguns bancos n\u00e3o permitem mais que uma instru\u00e7\u00f5es no mesmo statement ent\u00e3o teria de executar o comando set numa execu\u00e7\u00e3o e sua senten\u00e7a SQL na seguinte. Ent\u00e3o dependendo do banco de dados que for usar com o Zeos voc\u00ea pode economizar statement com Properties<\/strong>.<\/p>\n\n\n\n
ReadOnly<\/h2>\n\n\n\n
Tipo “true” ou “false”. Quando “true”, os dados poder\u00e3o ser lidos, mas nunca alterados. Vale ressaltar que se uma query ser\u00e1 do inicio ao fim sempre read only<\/strong> ent\u00e3o seria melhor usar o componente TZQueryReadOnly<\/strong> onde apesar do mesmo objetivo, nunca poder\u00e1 mudar seu estado para realizar altera\u00e7\u00f5es ou ser usado em conjunto com TZUpdateSQL.<\/p>\n\n\n\n
Sequence e SequenceField<\/h2>\n\n\n\n
\u00c9 usado para obter uma sequencia num\u00e9rica do objeto do tipo SEQUENCES no banco de dados. At\u00e9 o Firebird2.5 usava-se este tipo de dados para obter sequencias que geralmente eram usadas como autoincremento dentro das tabelas. A partir da vers\u00e3o 3.0, o FirebirdSQL ganhou o tipo “autoincremento” para tabelas e n\u00e3o carece mais de usar SEQUENCES para este fim, mas voc\u00ea ainda pode usar um SEQUENCES para outras finalidades.<\/p>\n\n\n\n
ShowRecordTypes<\/h2>\n\n\n\n
Permite exibir uma coluna virtual que indica o tipo de opera\u00e7\u00e3o \u00e9 efetuada com o registro antes do CommitUpdates, a saber: <\/p>\n\n\n\n
usUnmodified: N\u00e3o modificado<\/li>
usModified: Modificado<\/li>
usInserted: Inserido<\/li>
usDeleted: Exclu\u00eddo<\/li><\/ul>\n\n\n\n
O Firedac no Delphi tem algo similar quando estamos usando Cached Updates, usamos para entender num conjunto de dados, o que ser\u00e1 exclu\u00eddo, modificado ou inserido antes do CommitUpdates. N\u00e3o h\u00e1 documenta\u00e7\u00e3o farta em como mostrar essas opera\u00e7\u00f5es no Zeos, mas presume-se algo similar ao Firedac com cached updates, por exemplo, se “usDeleted” estiver ligado neste set e CachedUpdates estiver ativo ent\u00e3o ser\u00e1 poss\u00edvel ver todos os registros exclu\u00eddos.<\/p>\n\n\n\n
SortedFields<\/h2>\n\n\n\n
Lista de campos para ordena\u00e7\u00e3o, geralmente usado em conjunto com a propriedade SortType<\/strong>. Muitas vezes \u00e9 mais pr\u00e1tico usar SortedFields e SortType do que IndexFieldNames na programa\u00e7\u00e3o, veja o exemplo abaixo onde ao clicar no titulo de uma coluna no DBGrid haver\u00e1 uma ordena\u00e7\u00e3o pelo campo seja ascendente ou descendente se clicar nele uma segunda vez:<\/p>\n\n\n\n
Tipo String. \u00c9 a senten\u00e7a SQL propriamente dita. Use o ParamChar “:” quando desejar usar par\u00e2metros ou referenciar campos noutro resultset especificado em MasterSource. <\/p>\n\n\n\n
UpdateMode<\/h2>\n\n\n\n
Set de Valores. Com o CachedUpdates (ou RequestLive com ZTable) ativo voc\u00ea pode alterar os valores locais e eles ser\u00e3o enviados ao servidor ap\u00f3s o ApplyUpdates. Para que isso funcione, o sistema gerar\u00e1 querys dinamicamente para aplicar essas atualiza\u00e7\u00f5es e ele tem basicamente dois m\u00e9todos onde poder\u00e1 localizar os registros originais que precisam ser atualizados:<\/p>\n\n\n\n
umUpdateAll<\/strong>: Usa todos os campos, modificados ou n\u00e3o. Como se percebe \u00e9 anti-perform\u00e1tico.<\/li>
umUpdateChanged<\/strong>(default): Atualiza apenas os campos que foram modificados, neste caso voc\u00ea precisa ter uma primary key(PK) para ele saber gerar adequadamente a clausula where do SQL. Esse m\u00e9todo \u00e9 importante tamb\u00e9m para caso duas ou mais pessoas alterem o mesmo registro na rede, por\u00e9m cada um deles gerar\u00e1 um update apenas dos campos que cada um modificou mantendo um mix de atualiza\u00e7\u00f5es, n\u00e3o sobrepondo valores inalterados.<\/li><\/ul>\n\n\n\n
UpdateObject<\/h2>\n\n\n\n
Referencia um TZUpdateSQL. Com um TZUpdateSQL em seu sistema voc\u00ea pode construir seu INSERT\/UPDATE\/DELETE de forma que uma altera\u00e7\u00e3o visual de um registros possa ser aplicado do jeito que voc\u00ea deseja. \u00c9 muito mais pr\u00e1tico do que escrever INSERT\/UPDATE\/DELETE na unha.<\/p>\n\n\n\n
WhereMode<\/h2>\n\n\n\n
Set de Valores. Quando essas queries de INSERT\/UPDATE\/DELETE s\u00e3o criadas dinamicamente, ser\u00e1 necess\u00e1rio localizar corretamente os registros originais que sofrer\u00e3o a a\u00e7\u00e3o.<\/p>\n\n\n\n
wmWhereAll<\/strong>: Todos os campos ser\u00e3o referenciados na clausula WHERE do SQL para localizar o valor original. Anti-perform\u00e1tico. S\u00f3 faz sentido essa op\u00e7\u00e3o em dados n\u00e3o “normatizados” ou “bagun\u00e7ados”.<\/li>
wmWhereKeyOnly<\/strong>: Usa apenas a primary-key como referencia.<\/li><\/ul>\n\n\n\n
Conclus\u00e3o<\/h2>\n\n\n\n
O componente TZQuery \u00e9 o mais usado dentro de um programa. Embora todas as explica\u00e7\u00f5es mencionados aqui sejam para o Zeos, muitas outras su\u00edtes tem propriedades bastante similares. Ent\u00e3o, se domin\u00e1-los no Zeos, voc\u00ea leva este conhecimento tamb\u00e9m para outras frameworks de acesso a dados.<\/p>\n\n\n\n
S\u00e9rie de v\u00eddeos<\/h2>\n\n\n\n
Siga a playlist abaixo e veja o uso das propriedades na pr\u00e1tica:<\/p>\n\n\n\n
![\"\"](\"https:\/\/gladiston.net.br\/wp-content\/uploads\/2022\/03\/zquery_calculated.png\")