Revista The Club Megazine - 06/2002
A utilização, reprodução, apropriação, armazenamento em banco de dados,
sob qualquer forma ou meio, de textos, fotos e outras criações intelectuais
em cada publicação da revista “The Club” são terminantemente proibidos
sem autorização escrita dos titulares dos direitos autorais.
Copyright © The Club® 2002
Editorial
Editorial
Olá Amigos,
THE CLUB
Rua Acre, 950 - Avaré - SP - CEP 18.700-260
Informações: (0xx14) 3732-3689
Suporte: (0xx14) 3733-1588 - Fax: (0xx14) 3732-0987
Internet
http://www.theclub.com.br
Cadastro: [email protected]
Suporte: [email protected]
Informações: [email protected]
Dúvidas
Correspondência ou fax com dúvidas devem ser
enviados ao - THE CLUB, indicando "Suporte".
Opinião
Se você quer dar a sua opinião sobre o clube em
geral, mande a sua correspondência para a seção
Neste mês nós estamos trazendo informações muito importantes
para você. A Borland mostra o preview do novo Delphi. A maior
novidade é que o novo Delphi está seguindo em direção ao .NET. A
Borland anuncia também o fim do BDE. Outra informação muito
importante para quem trabalha ou pretende trabalhar com automação
comercial é a padronização de DLLs utilizadas em impressoras fiscais.
Para quem trabalha com Palm, vamos aprender a trabalhar com FTP
neste ambiente. E ainda nesta edição vamos começar uma série sobre o
DataSnap.
Como você mesmo pode ver, esta edição está recheada de novidades e
no mês que vem tem mais.
Até lá.
"Tire sua dúvida".
Reprodução
A utilização, reprodução, apropriação,
armazenamento em banco de dados, sob qualquer
forma ou meio, de textos, fotos e outras criações
intelectuais em cada publicação da Revista
“The Club” são terminantemente proibidos sem
autorização escrita dos titulares dos direitos
autorais.
Celso Jefferson Paganelli
Presidente - The Club
Copyright© The Club® 2001
Impressão e acabamento:
Impressos Gril - Gril Gráfica e Repr. Ind. Ltda.
Tel.: (0xx14) 3762.1345 - Fax: (0xx14) 3762.1259
Rua São Paulo, 447 - Cep 18.740-000
Taquarituba - SP
Tiragem: 5.000 exemplares
Diretor - Presidente
Celso Jefferson M. Paganelli
Diretor Técnico
Mauro Sant’Anna
Colaboradores
Claudenir C. Andrade - Mário Camilo Bohm
Marcio Alexandroni da Silva
Anderson H. Rodrigues
Delphi é marca registrada da Borland
International, as demais marcas citadas são
registradas pelos seus respectivos proprietários.
Editorial ......................................................................................... 03
News ......................................................................................... 04
Lendo informações de configuração ................................................ 07
DLL Padrão - Universalização das impressoras fiscais ...................... 10
O futuro do BDE e do SQL Links ...................................................... 14
Controlar fidelização de clientes no ECF ......................................... 15
DataSnap - Parte 1 ......................................................................... 16
LFTP - Palm ................................................................................... 21
Traduzindo as mensagens do Delphi via Translation Manager ............ 23
Perguntas & Respostas .................................................................... 27
MeGAZINE
3
NEWS
Promoção Especial: Banco de Dados ADS para 2 Usuários Grátis para
Desenvolvedores Clipper e VO.
A ReNet Tecnologia Ltda., distribuidora da Extended
Systems no Brasil, cederá em Julho/2002 para desenvolvedores
Clipper ou VO que tenham este software registrado, uma licença
de uso para 2 usuários do servidor ADS (Advantage Database Server)
para utilização em seu ambiente de desenvolvimento e testes.
Visite www.renet.com.br, cadastre-se em nossa área de
download e nos envie por fax (11 3872-4418) cópia do cartão de
registro de sua licença de uso do Clipper ou do VO, informando o
sistema operacional de rede desejado (NetWare, Linux, Windows
NT/2000 ou Windows 9x). Após, a ReNet enviará email
informando situação da solicitação e procedimento necessário
para o download do ADS. Os dados para ativação serão fornecidos
no termo de cessão de direitos de uso.
A licença para 2 usuários a ser cedida é para uso interno do
desenvolvedor e não poderá ser revendida, distribuída ou
transferida. Somente será cedida uma licença por desenvolvedor.
Visite www.renet.com.br para conhecer o ADS, clientes
nacionais e internacionais e lista completa de funcionalidades
presentes e futuras, ou contate-nos no telefone abaixo.
ReNet Tecnologia Ltda.
[email protected]
Tel.: 11 3872-0423
Fax: 11 3872-4418
A Disneylândia dos geeks
No dia 3 de junho de 2002 o jornal O Globo mostrou na capa
do seu caderno de Informática a seguinte frase: A Disneylândia
dos geeks, se referindo a Borland Conference 2002. Veja abaixo a
matéria.
Está surgindo uma nova aurora na tecnologia da
informação, e sua gênese pôde ser vislumbrada na Borland
Conference (BorCon) deste ano, que aconteceu neste resort do
oeste americano onde fica a Disneylândia original. Aurora, não
por acaso, é um dos codinomes das futuras linguagens de
programação que a empresa pretende lançar no segundo
semestre deste ano e no começo de 2003, que podem mudar a face
do e-business e da própria internet, tornando-a mais ubíqua do
que já é, através dos tão cantados e decantados web services.
A conferência é um mar de geeks do mundo inteiro, e
nenhuma palestra está completa sem a inclusão de várias linhas
de código. Mas, ao contrário da MacWorld, em que Steve Jobs
gosta de posar de Deus para uma platéia boquiaberta, a BorCon é
uma mega-reunião de família, capitaneada e organizada pelo GG
David Intersimone (ou David I, seu nome “oficial” na comunidade
de programadores), em que é impossível não se sentir à vontade.
A festa começa no próprio keynote de abertura, em que David —
vice-presidente de relações com desenvolvedores e um dos pilares
da comunidade Borland (está na empresa desde a fundação, em
1983) — faz um monte de brincadeiras antes de anunciar as
novidades, geralmente de bermuda e camiseta.
Este ano, porém, quando as luzes se apagaram no salão de
baile do Anaheim Convention Center, começou a tocar a músicatema dos filmes de 007 e logo o impagável David — uma figuraça
barbuda e bonachona de 1,90m de altura — surgiu de smoking e
pistola em punho, numa entrada triunfal. No telão, aparecia um
dos “filmes” de “David Bond”: “Licenced to Code” (“Licenciado
para programar”). Pouco depois, entrou o CEO Dale Fuller e o
keynote começou para valer.
Nova linha de desenvolvimento em Java
Não houve nenhuma chuva de lançamentos de caixinhas ao
4
longo do evento, com a exceção da nova linha “javanesa” para
desenvolvedores: o JBuilder 7 (nova versão do ambiente de
desenvolvimento Java da Borland), o Enterprise Studio 4 para
Java (que integra todos os elementos do ciclo de criação de uma
aplicação) e a Optimizeit Suite 4.2, voltada para aplicações mais
robustas. Mas o que chamou mesmo a atenção foram os previews
dos futuros Delphi, Kylix e C++. Os ambientes estão seguindo
irreversivelmente em direção ao .NET da parceira Microsoft, aos
web services e à conversa livre entre aplicações nas mais diversas
plataformas, do PC ao celular.
Foi, de fato, muito interessante essa prévia de como o
framework vai se comportar — diz João Carlos Bolonha,
consultor técnico da equipe de projetos especiais da Borland no
Brasil. — A idéia é portar o código que você já tem hoje até o
mundo .NET. Praticamente todas as funcionalidades que você
tem hoje no Delphi estarão disponíveis para o .NET, e foi
mostrado um preview do compilador, os caminhos de migração...
Envolvendo Kylix e Delphi, o ponto principal foi esse.
No caso do C++, ele será usado com o Kylix (o Delphi para
Linux) e também portado para desenvolvimento (como o Java já
é, via JBuilder MobileSet, por exemplo) em celulares 2.5G e 3G,
bem como PDAs, smartphones e outros micrinhos com o sistema
operacional móvel Symbian. Isso significa, entre outras coisas,
programar confortavelmente em simuladores de celulares dentro
do PC.
Ao usar o JBuilder MobileSet, você pode ter um simulador do
Nokia Communicator ou de um aparelho Sony Ericsson em seu
PC enquanto desenvolve ou debuga algo. O J2ME (Java 2 Micro
Edition) também tem uma API padrão para esses simuladores —
explica David. O C++ funcionará de maneira semelhante. No
keynote de abertura, foi mostrado como os ambientes de
desenvolvimento eram rapidamente compilados de um notebook
para um PC com monitor removível e para um celular. Ficou
todo mundo babando...
A “nomenclatura” das futuras linguagens foi fornecida em
MeGAZINE
NEWS
outro keynote, o de Michael Swindell, diretor de tecnologia do
grupo de RAD (Rapid Application Development) da Borland. O
supracitado Aurora é o nome “secreto” do Delphi 7, que virá com
um compilador para o .NET; depois chega o Galileo, o Delphi para
o .NET (a linguagem é definida como um puro ambiente de
desenvolvimento multiplataforma para a arquitetura da MS); e,
por fim, o Charlotte, uma nova linguagem de programação
especialmente voltada para criar e “scriptar” web services. No
campo móvel, haverá primeiro um C++ com plugins para o
Symbian OS e depois um C++ Builder para o sistema.
Keynotes de Microsoft, Intel e Sun
Nem só de Borland se alimentaram os keynotes do evento. As
parceiras Microsoft, Sun e Intel também fizeram os seus. Da
última, veio Chris Thomas, ex-estrategista chefe, que vaticinou
que estamos num novo momento de mudanças drásticas ao
tascar no telão a frase de Gordon Moore: “Você nunca sai de uma
recessão com a mesma tecnologia com que entrou nela”. Olhando
para trás, dá mesmo o que pensar. Thomas analisou as
mudanças que levaram do mainframe ao PC e do PC à internet.
E a pergunta que ficou no ar foi: o que vem depois da web? Para
ele, a resposta é a interação entre aplicações via padrões da Rede,
isto é, os web services. Eles de novo.
Hoje, as aplicações são a chave para eles — disse. — A
padronização expande as oportunidades e a melhor escolha é não
escolher. E o catalisador desta inovação é a mudança de
arquiteturas e plataformas proprietárias para plataformas
baseadas em standards.
A Microsoft, naturalmente, entoou loas à sua nova
arquitetura. Levou para isso um nome de peso, Anders
Hejlsberg, principal designer do C# (C “sharp”) e um dos
criadores do Turbo Pascal. Sua palestra foi eficiente, mas, como
confidenciou um veterano programador, “puxa vida, com esse
negócio do .NET está todo mundo amiguinho aqui este ano! Não
se fala mais mal da MS...” E da Sun veio James Gosling, o pai do
Java, que, de acordo com o tom da BorCon, sentenciou: nada é
mais stand-alone hoje. O que importa são sistemas, não programas,
e o desenvolvimento/design integrado de ponta a ponta. O
exemplo em Java foi uma demo da total simbiose dos serviços
num posto de gasolina, por exemplo, com tudo cúmplice de tudo
na parte digital: a bomba de combustível, a cobrança, as
máquinas de refrigerante e assim por diante.
Fonte: Jornal O Globo 03/06/2002
MeGAZINE
5
NEWS
O futuro da tecnologia é a integração
Eles fazem (quase) tudo juntos, incluindo keynotes. Nas
entrevistas não podia ser diferente. O CEO da Borland, Dale
Fuller, e o vice-presidente de relações com desenvolvedores, David
I, são o retrato de um modo especial de gerir negócios. Totalmente
integrados à sua comunidade de programadores, ambos
passaram madrugadas na BorCon conversando com a galera
e ouvindo as mais variadas sugestões. Aqui, falam do futuro da
TI.
O futuro são mesmo os web services? Como eles vão mudar a
cara da internet?
DALE FULLER: Os web services são as linguagens de
comunicação entre aplicações diferentes, díspares, e essa
interoperabilidade é o futuro. A força da tecnologia, hoje, está
nisso — como conectamos melhor hardware, pessoas, aplicações.
As aplicações de software se tornam mais poderosas à medida
que conversam entre si num nível cada vez mais fluido.
DAVID I: A vantagem dos web services é que eles são uma
interface. Você trabalha com interfaces, e programadores
entendem bem as interfaces, já que elas estão aí faz algum
tempo. Segundo, eles são baseados em descrições de texto das
interfaces, bem como dos parâmetros e seus tipos, usando XML.
Terceiro, são baseados num protocolo que todo mundo conhece e
entende, que é ubíquo.
Quando veremos tudo funcionando, conectado entre si?
DALE: Não creio que veremos tudo conectado a tudo. Mas
estamos começando a ver a integração. O Java foi a primeira
tentativa, e vem fazendo um ótimo trabalho, via J2EE, para
permitir que a interoperabilidade atravesse plataformas
distintas. Foi um marco nessa caminhada, pois antes disso eu só
podia escrever aplicações para uma plataforma específica, e só se
podia falar com outras através de RPCs, mas era tudo a mesma
plataforma. O Java mudou isso. E agora vem o .NET e, o mais
importante, os web services em cima, integrando tudo. Tende-se
a ver mais e mais integração de aplicações e dispositivos — por
exemplo, mais conexões com programas em aparelhos wireless
nos próximos 18 a 24 meses, mais integração entre aplicativos
via XML, via UDDI [ Universal Description, Discovery and Integration,
diretório web que permite a empresas se listarem e se descobrirem rapidamente
na rede ]. Mas você tem de lembrar que ainda há uma tremenda
quantidade de software legado [ legacy software, aplicações próprias de
uma empresa — como bases de dados — que geralmente rodam em seus
mainframes ou computadores de médio porte ] que não chegará lá tão
cedo. Vamos precisar integrar tudo, não será o caso de apenas
6
dar um salto para o futuro. Sabemos que hoje mais de 50% das
aplicações rodando no mundo, nos computadores das empresas,
ainda são baseadas em Cobol, escrito nos anos oitenta... De modo
que sabemos ter uma grande oportunidade com as novas
tecnologias, mas não podemos esquecer o passado. E esta é nossa
missão na Borland: ajudar as pessoas a entrar no futuro sem
esquecer o passado.
Não é difícil para vocês navegar através de tantas
plataformas por vezes conflitantes entre si, como Java, Windows
e .NET, Linux?
DALE: Oh, é um bocado difícil ( risos ). Por isso conto com um
pessoal capaz de reunir as complexidades e fazê-las parecer
simples para o usuário. É o que fazemos: buscamos capacitar o
novo mundo digital. Não criamos o Linux, nem o Java, apenas os
disponibilizamos para que as pessoas os usem em seu benefício.
Quais as características mais importantes dos vindouros
Delphi 7 e Kylix 3?
DAVID: No Delphi 7, a idéia é preparar cada vez mais todo
mundo para o .NET, que está saindo do forno. A primeira fase
consiste em usar um compilador do Delphi para o .NET, bem
como nossa biblioteca de componentes, construída em cima do
framework do .NET. Assim, eles poderão criar aplicações para o
ambiente. A segunda fase será a integração com designers etc,
permitindo às pessoas usar e desenvolver para o .NET. No
primeiro semestre de 2003 haverá integração total de nossos
produtos com o .NET e novas tecnologias nesse sentido virão. No
Kylix 3, a pedida é o trabalho conjunto do C++ com o Delphi em
Linux, usando nossa biblioteca CLX.
Como está indo a Borland no Brasil? Como será a primeira
BorCon nacional, em agosto, em São Paulo?
DAVID: Será junto com a Comdex. Farei um keynote sobre a
história da programação e para onde ela está indo, incluindo os
web services.
DALE: O mercado brasileiro é muito interessante. Uma das
três companhias que adquirimos no ano passado é brasileira, a
ATC. Estamos animados com os investimentos que fizemos no
país. Achamos que o Brasil e, na verdade, todo o hemisfério sul,
podem liderar a carga em direção à maior explosão de tecnologia
da informação que o mundo já viu.
Fonte: Jornal O Globo 03/06/2002
MeGAZINE
.NET
Lendo Informações
de Configuração
Por Mauro Sant’Anna ([email protected]). Mauro é um “MSDN Regional
Director”, consultor e instrutor da MAS Informática (www.mas.com.br), tendo
ministrado treinamentos na arquitetura .NET desde outubro de 2000.
Neste artigo veremos como foi a evolução do armazenamento
e leitura das informações de configuração dos programas nos
sistemas operacionais da Microsoft, desde o DOS até o .NET e
exemplos de como fazê-lo no .NET.
No início era o DOS
O sistema operacional DOS não definia uma maneira como
deveriam ser armazenadas as informações de configuração; cada
programa fazia o que queria; uma solução comum era gravar
arquivos binários no diretório do programa.
O Windows 3.0 introduziu os arquivos .INI para armazenar
as próprias informações de configuração e disponibilizou funções
para que os aplicativos pudessem fazer o mesmo. Os arquivos
.INI tinham várias vantagens:
· Suporte do sistema operacional para ler e escrever
informações;
· Usavam o sistema de arquivos para armazenar os dados,
com todas as facilidades de cópia, back-up e uso em rede. local;
· Podiam ser alterados com qualquer editor de texto em caso
de “emergências”;
O Windows 95 introduziu o “Registry”, uma base de dados
global gerenciada pelo Windows para armazenar informações de
configuração. O Registry traria as seguintes vantagens:
· Estrutura de dados hierárquica, com tipos de dados
bastante variados
· Separação das informações do usuário (sob a chave HKCU)
e as do equipamento (sob HKLM)
· O sistema operacional poderia trocar partes do Registry
assim que o usuário fizesse login, de forma a permitir que um
usuário pudesse usar qualquer computador da rede.
Problemas no Paraíso
Podemos dizer hoje que o Registry foi uma idéia que não deu
certo. Em primeiro lugar, ele não acrescentava nenhum recurso
que não poderia ser fornecido pelo próprio sistema de arquivos.
Por exemplo, poderíamos guardar informações de configuração
em diretórios especificados pelo sistema operacional e ter desta
forma todas as vantagens introduzidas pelo Registry.
O Registry introduziu diversos problemas que não existiam
anteriormente:
· É uma base de dados que pode ser corrompida e tornar o
sistema inoperável;
· É difícil fazer back-up e restore (bem mais difícil que nos
arquivos do disco)
· O Registry acaba acumulando lixo e ficando cada vez maior
e existem limites de tamanho do Registry que podem ser
ultrapassados, mesmo no Windows XP
· A troca de informações de HKCU quando o usuário faz
login revelou-se muito lenta e viável apenas em redes locais
rápidas.
Configuração .NET
Na plataforma .NET a Microsoft voltou atrás: os programas
.NET não usam o Registry e sim arquivos-texto. Não que o
Windows deixe de ter um Registry depois da instalação do .NET:
ele não só continua com o Registry como também recebe mais
MeGAZINE
7
.NET
algumas entradas. O que queremos dizer é que os programas
.NET não precisam (e não devem) usar o Registry para nada. Os
arquivos-texto nos quais devemos colocar informações de
configuração são no formato “.INI dos anos 2000”, ou seja, o
XML.
Existem vários arquivos XML com informações de
configuração:
· security.config: Informações de segurança. Não deve ser
editado diretamente, use o aplicativo gráfico “.NET Framework
Configuration tool” (Mscorcfg.msc) ou o aplicativo de linha de
comando “caspol.exe”; você pode criar programas “.bat” com o
caspol.exe de forma a automatizar a aplicação de configurações
complexas;
· machine.config: Informações globais de configuração do
computador. Pode ser alterado para conter informações de vários
programas, mas torna inviável a “instalação com xcopy”;
· web.config; Informações de configuração de aplicativos Web;
· “nome.exe.config”: Informações de configuração de
aplicativos não-Web; deve ter o mesmo nome do executável e
estar presente no mesmo diretório.
Estamos interessados nos dois arquivos associados ao
aplicativo. Embora possam conter informações diferentes e
tenham nomes diferentes, eles têm várias coisas em comum:
· São opcionais; seu aplicativo pode omiti-los;
· Podem conter entradas que não tem nada a ver com
informações que você esteja
diretamente interessado em
ler; por exemplo, opções de
depuração ou diretórios
onde se encontram outras
DLLs;
· Definem seções
específicas para
armazenamento de
informações de
configuração do usuário
Os arquivos associados
ao aplicativo podem conter
uma entrada especialmente
criada para conter
informações de
configuração chamada
“appSettings”. Veja um
trecho do arquivo de
configuração com esta
opção:
<!—Outras entradas vão
<appSettings>
<add key=”Nome1"
<add key=”Nome2"
<add key=”Nome3"
</appSettings>
value=”Valor1" />
value=”Valor2" />
value=”Valor3" />
</configuration>
A primeira entrada acima pode ser lida com apenas uma
linha de código:
Using
System.Configuration;
string Valor =
ConfigurationSettings.AppSettings[“Nome1”];
Um exemplo com aplicativo Windows
Uma situação comum é ler a string de inicialização do banco
de dados a partir do arquivo de configuração. Desta forma,
podemos alterar informações do banco sem ter que recompilar o
programa.
Crie um aplicativo novo “Windows Appplication” em C# com o
nome “WinApp.exe”. Coloque um Button e um ListBox:
<?xml version=”1.0"
encoding=”utf-8" ?>
<configuration>
8
aqui —>
MeGAZINE
.NET
Crie com o Notepad um arquivo chamado
“WinApp.exe.config” NO MESMO DIRETÓRIO DO
EXECUTÁVEL, por exemplo, \bin\debug com o seguinte
conteúdo:
Observe que teremos que colocar a seção “<appSettings>”
dentro da seção <configuration> já existente.
Adicione um Button e um ListBox ao aplicativo:
<?xml version=”1.0"
encoding=”utf-8" ?>
<configuration>
<appSettings>
<add key=”StrCnx”
value=”Database=Pessoal;
uid=appuser;pwd=tri08lk”/>
</appSettings>
</configuration>
Pode ser que este arquivo já exista,
neste caso inclua a seção “<appSettings>”
dentro da seção <configuration> já
existente. O código no evento Click do
botão é o seguinte:
string StrCnx =
System.Configuration.
ConfigurationSettings.
AppSettings[“StrCnx”];
listBox1.Items.Add(StrCnx);
Um exemplo com aplicativo
Web
Crie um aplicativo Web em C# com o nome “WebApp”.
Observe que existe um arquivo web.config já criado. Dê um
clique duplo para editá-lo:
O código no evento Click do botão é o
seguinte:
string StrCnx =
System.Configuration.
ConfigurationSettings.
AppSettings[“StrCnx”];
ListBox1.Items.Add(StrCnx);
Ler informações de configuração na
plataforma .NET é algo bastante simples
e que não sofre dos problemas do
Windows com o Registry.
Caso você queira também gravar
informações, a maneira “oficial” é criar
um arquivo XML e gravá-lo no diretório
do aplicativo. Ler e escrever é mais difícil,
contudo, pois exige conhecimentos mais
profundos de XML e a classe
XMLDocument.
MeGAZINE
9
Delphi
Dll Padrão
(Universalização das Impressoras Fiscais)
Por Claudenir C. Andrade
Em nosso país, com a saída de dois expressivos fabricantes de
Automação Comercial, permanece no país mais cinco fabricantes
de impressoras fiscais. Um dilema enfrentado por muitas
software-houses é a necessidade de se falar com vários
fabricantes de impressoras fiscais. Hoje é necessário um controle
detalhado no software para fazer com que um programa de
frente de caixa “fale” ou funcione com todas as impressoras de
mercado. Para isso o software deverá conter vários flags,
controles, Ifs etc. mais ou menos assim:
If Bematech
Bematech_FI_AbreCupom(“212132”);
If Yanco
Y200_Fiscal(“ESC32”)
If GSV
....
Sem sombra de dúvidas isso dificulta e requer um controle
muito detalhista do software e com isso um conhecimento muito
profundo de cada periférico fiscal, para saber qual função
chamar, a seqüência de escape correta, etc.
Pensando nisso a Afrac resolveu criar um “padrão
documental” de uma interface de comunicação com as
impressoras fiscais. Isso significa que quando você chamar a
função Afrac_AbreCurpom(“xxx”) esta função servirá para todas
as impressoras fiscais, abrindo cupom para todas as impressoras
fiscais existentes no mercado. Eu acompanhei muito das
reuniões do grupo técnico para a construção desta interface (que
considero um sub-set da interface que construímos na
Bematech) e muitas funções foram acrescentadas e corrigidas
nestas reuniões. No final de tudo isso, saiu um documento ou
normalização de construção de interface para impressoras
fiscais, ou seja, se um fabricante deseja estar dentro desta norma
deverá construir sua dll com base nesta norma escrita.
Do outro lado, no lado do desenvolvimento de software, o
10
desenvolvedor poderá chamar a função
AFRAC_AbreCupom(“xxx”), o único trabalho ou diferença será
que o desenvolvedor deverá baixar a dll do fabricante com estas
funções. Não haverá uma ÚNICA dll que converse com todas as
impressoras fiscais, mas sim cada fabricante fornecerá sua dll
com base no padrão escrito pela Afrac.
O Fabricante Y gera uma dll com seu protocolo de
comunicação, o Fabricante X com seu protocolo e o Fabricante Z
também, com seu protocolo e sua regra de negócios. Quando uma
software house necessitar utilizar a Impressora do Fabricante Y.,
então ele somente baixaria a dll de seu site e instalaria no PDV,
quando necessitasse utilizar o ECF do fabricante X também,
baixaria a dll deste fabricante e instalaria no PDV. Este é o
padrão de interface estabelecido pela Afrac (Associação de
Fabricantes e Revendedores de Automação Comercial).
Sem dúvida nenhuma a proposta da Afrac de ter este padrão
de comunicação é o ideal para atender a todos nós
desenvolvedores que trabalhamos com Automação Comercial.
Todos os Fabricantes estão aderindo a esta modalidade, a
Bematech tem por previsão futuramente ter esta dll também.
Mas existem questões que em meu ponto de vista não foram
pensadas no momento em que se pensou na padronização das
impressoras fiscais. Esta padronização chega em um momento
não adequado e sem nenhuma força frente a necessidades do
mercado, das software houses. Porque? Existem várias questões
envolvidas vamos analisá-las:
1) A Afrac não está propondo nada de Novo, toda a
documentação da Interface Padrão é Baseada 90% em DLL de
comunicação do Fabricante Bematech, que por vários anos já
possui uma interface em Alto-Nível, como o proposto pela Afrac
2) A Afrac em nenhum momento está se responsabilizando
pelo avanço tecnológico desta interface Padrão, tendo em vista
que existirá uma padronização de todas as interfaces, muitos
fabricantes olharão para esta padronização com bons e maus
MeGAZINE
Delphi
olhos. O que levaria o Fabricante Y gastar tempo e dinheiro
pensando em novas funcionalidades para a Interface Padrão
quando todos os fabricantes (Que são concorrentes) usufruiriam
um trabalho realizado? Quem arcaria com a despesa da pesquisa
e do tempo de desenvolvimento? Esta falta de definição
infelizmente levará a interface para o caminho do Obsoleto, pois
todos os Fabricantes concorrentes estarão esperando um ao outro
que lance e crie novas funcionalidades, como nenhum deles o
fará, pois isso beneficiará seu concorrente também, a interface
estará fadada a não evoluir.
3) Um fator a ter em mente é que a Interface Padrão não
siga a união de todos os Fabricantes , os fabricantes continuam
sendo concorrentes, continuam se diferenciando pelo suporte em
suas dll nativas (fora do padrão) e continuarão a investir
(Tempo e Dinheiro) para a evolução tecnológica de suas dlls e
drivers nativos, e não da Interface padrão Afrac, pois isso
significaria gastar tempo e dinheiro para que seus concorrentes
também se beneficiem. O resultado disso será o status estagnado
da dll.
4) Suporte será o diferencial – Não estou falando aqui do
suporte telefônico ou em campo que muitos fabricantes tem se
destacado, mas falo do suporte tecnológico, das parcerias de
tecnologia. Todos os fabricantes irão manter em paralelo suas dll
Nativas existentes e gastarão Tempo e Dinheiro para criação de
novas funções - TEF, Relatórios da Legislação, Comunicação
nativa com outros periféricos de AC, Funções cada vez mais
inteligentes e completas – Todos estes ‘features’ continuarão a
evoluir na dll Nativa e não na interface padrão, porque isso
significaria que também o concorrente, sem esforço nenhum,
teria este ‘feature’ documentado e pronto para implementar, sem
gastar tempo, sem gastar dinheiro, sem ocupar sua equipe de
desenvolvimento, sem gastar tempo em testes, liberação etc., pois
uma vez que algum fabricante tenha documentado este novo
‘feature’ na Interface Padrão, todos irão usufruir.
Estes são apenas alguns pontos a serem pensados quanto à
decisão do uso de uma interface Genérica ou não. Infelizmente
esta padronização nasce somente agora, quando na verdade
deveria nascer desde o Firmware, desde seu Set de comandos,
desde o Hardware Fiscal, e não em uma camada intermediária
como uma simples dll, porque? Explico.
No Brasil, mesmo com a existência de uma lei fiscal, existem
diferenças operacionais entre as impressoras fiscais, existe
literalmente diferenças de Escapes de comando no Firmware de
uma impressora fiscal para outra impressora. Isso é a real
impossibilidade de se ter uma padronização. Muitas empresas
investiram no padrão OLEPOS e WOSA vários outros padrões
para o desenvolvimento de software para pontos de venda e
Automação de Bancos, mas nenhum deles decolou exatamente
por dois motivos, um deles o foi o obsoleto que ficou a interface,
por não acompanhar o mercado tecnologicamente, e outro dele é
que todo padrão é um Sub-Set, queira ou não todo padrão é um
sub-set.
Conforme comento, mesmo com uma lei de Homologação
Única para as impressoras ficais, existem diferenças
significativas de “features” entre uma impressora fiscal e outra,
como por exemplo, o número de linhas em uma mensagem
promocional, impressão no verso de um cheque ou não,
cancelamento e um último cupom após a emissão de um
vinculado não fiscal, tabela de retorno de status de uma
impressora fiscal, cancelamento de um item, informações da
impressora em número de bytes etc.., Toda esta
“despadronização” nasceu de berço, no firmware que é
homologado pelos fabricantes em órgãos nomeados pelo governo a
homologar e aprovar o uso de impressoras fiscais no Brasil.
Isso que comento, significa que em um estudo realizado a
interface nasce com 40% menos de operações que qualquer dll
nativa oferecida hoje por um fabricante de Automação Comercial
e a redundância de verificações dentro do código fonte, para
identificar o fabricante, ainda irá continuar e o software ainda
terá que ter seus “Ifs” para determinadas operações.
Dando um exemplo para entendermos a diferença entre uma
dll nativa por um fabricante e uma interface padrão é o caso do
Veículo Gol 1.0, Gol 1.6 e Gol 1.8, todos estes modelos de GOL têm
algo em comum? Tem sim, todos podem andar no mesmo ritmo e
na mesma velocidade que o 1.0. Você não estaria utilizando toda a
potência oferecida pelo Gol 1.8 e 1.6, pois para igualar estaria
desperdiçando quase menos da metade da potência oferecida pelo
veículo. Ou seja, como não existe padrão de velocidade, marca,
cavalos, válvulas etc.. Para padronizar estes três modelos, como
estão hoje sem mexer no motor, teríamos que sub utilizar o 1.6 e o
1.8 porque não é possível fazer que o 1.0 tenha o mesmo
desempenho e torque que o 1.6 e 1.8.
Idêntico ao exemplo acima é o caso dos ECFs no Brasil,
existem modelos de EFC com muito mais “features” (Gol 1.8) e
existem modelos de ECF com muito menos features (Gol 1.0).
Para criar um padrão entre estes equipamentos será necessário
sub-produtor ou descartar alguns features oferecidos pela
impressora e que estão presentes naturalmente na dll nativa do
fabricante. Isso implica em menos funções para o software e
talvez em mais trabalho para se obter um resultado uma vez que
com uma escrita e uso nativo de uma dll seria de imediato.
A falta de padronização no firmware e a tentativa da Afrac
de criar um padrão em DLL de comunicação não eliminará a
necessidade de verificação do software para identificar o
fabricante para a tomada de decisão em comandos simples como
Retorno do número de série da impressora, não são todos os
fabricantes que tem a mesma quantidade de bytes a serem lidos
pelo software e nem todos os fabricantes possuem a mesma
formatação de número de série de 4 Dígitos para modelo, e o
restante para Lote e Data. Isso significa que ainda será
MeGAZINE
11
Delphi
necessário um “IF” ou uma leitura de um arquivo para se saber quantos bytes aquele fabricante em questão retorna de maneira
que a Impressora que está rodando na “ponta” nunca será totalmente transparente para o software. Graficamente falando, a
padronização resultou no seguinte:
O resultado da Padronização entre os três ECFS será uma
interface com a seguinte característica de funções:
Abre Cupom
Isso porque este será o único comando em comum existente
entre os ECFs. O que aconteceria se a Interface padrão tiver o
comando de Função Comunicação TEF? Não iria funcionar no
ECF Y e no ECF Z, ou seja, o potencial oferecido por estes ECFs
juntamente com suas dlls nativas seriam desperdiçados. A
interface padrão possui uma tabela de “features” que indica o que
faz certo ECF ou não, esta tabela é fornecida pelo fabricante
juntamente com a Interface Padrão, mas isso diz então que a
interface não deixa a impressora transparente para o software e
voltamos no cenário atual de utilizarmos os Ifs nos softwares
para a identificação da impressora e do fabricante.
Por exemplo, como solucionar o caso do número de série ou do
status da impressora fiscal? Simples, se a padronização estivesse
nascido do Firmware esta iniciativa de padronizar a DLL seria o
ideal, pois TODOS os ecfs teriam os MESMOS comandos e uma
dll padrão não desperdiçaria o potencial de determinados ECFS e
suas DLL Nativas
10.6 Então o que usar? Dll Padrão ou Nativa?
Bem, isto é uma pergunta que o leitor já deve estar se
fazendo a altura deste capitulo. Não cabe a mim decidir isso, mas
vamos analisar o cenário atual do mercado de automação para
que possa nos ajudar a decidir esta questão.
12
Cada vez mais existe a necessidade de oferecer melhores
serviços para nossos clientes, oferecer uma solução e garantir seu
funcionamento.
Este é o cenário Atual do mercado, válido principalmente
para as empresas de software, que segundo o que vimos, tem o
perfil muito mais próximo de oferecer solução para o cliente.
Quando uma software-house decide deixar seu software
“falando” com qualquer impressora fiscal do mercado ela então
passa a utilizar a Interface Padrão, pois o discurso é que esta
interface padronizada pela Afrac se comunica com qualquer
impressora fiscal. Isso significa que sua empresa de software esta
se responsabilizando pelo uso de qualquer impressora.
O cliente quando tem um problema deseja uma solução o
mais rápido possível e o mais confiável possível, ainda mais
quando estamos falando de PDV, o ponto mais estratégico de um
estabelecimento comercial, sendo assim, se uma empresa de
software garante que seu produto funciona com qualquer
periférico fiscal, mesmo que indique uma marca, está se
responsabilizando pelo uso de outras marcas que não são tão
confiáveis assim e que não oferecem um suporte ou um pósvenda adequado, e quando este ecf apresentar problemas a
primeira empresa que o cliente entra em contato é a Software
House. Isso pode ser uma faca de dois gumes, você permitir que
seu software rode com qualquer periférico significa que você
homologou este periférico e o aprovou, de nada adiantaria
implementar a dll padrão AFRAC em seu software e não assumir
responsabilidade pelo uso de determinados modelos e marcas de
ECF. Seria totalmente incoerente o discurso de “Meu Software
MeGAZINE
Delphi
Fala com Qualquer ECF. Mas o X, Y, Z não aconselho, aconselho
que use apenas o ECF A e B”, sendo assim a pergunta é: Não
valeria a pena então desenvolver utilizando a dll Nativa do
fabricante A e B? Cabe a você decidir e responder. Mas antes
disso é importante que seja pensado e ponderado as questões
abaixo, que estou certo que o ajudará a tomar a decisão:
1) Tenho todas as funcionalidades necessárias para o término
de meu software?
2) Conseguirei oferecer a meu cliente, o potencial máximo
que o ECF possui?
3) Quando necessário terei atualizações de versão de acordo
com a legislação em sua totalidade, com Relatórios, etc?
4) Há Velocidade na solução de problemas?
5) Quanto tempo está no mercado a interface X?
6) Já está depurada e testada e aprovada por muitos
desenvolvedores?
7) Todos os fabricantes me oferecem uma pós-venda,
assistência técnica, suporte que necessito para estar garantindo o
uso de qualquer ECF em meu software?
8) Por quanto tempo as marcas X e Y permanecerão no
mercado?
9) Não estarei correndo riscos possibilitando a entrada de
qualquer hardware desconhecido em meu software?
Uma vez respondida estas questões com certeza você terá
tomado sua decisão, que seja qual for, sempre garanta que seu
cliente e você nunca ficarão na mão, e sempre estará na
vanguarda da tecnologia em Automação Comercial e que assim
você poderá sempre oferecer mais e melhores serviços a seus
clientes.
MeGAZINE
Claudenir é gerente de desenvolvimento de
software na Bematech e autor do livro “Automação
Comercial com C#, VB.NET e Delphi 6” lançado
pela Editora Érica – www.erica.com.br.
Ele também pode ser contatado pelo e-mail:
[email protected].
13
DELPHI
O futuro do BDE
e do SQL Links
A Borland revela os planos para o futuro do acesso a dados no
Delphi e no C++ Builder.
Em 2000 a Borland introduziu uma nova arquitetura de
driver SQL chamada dbExpress. O dbExpress foi desenhado
para ter um acesso extremamente rápido ao dados e de fácil
desenvolvimento e configuração.
O dbExpress é um driver de arquitetura SQL pura e não usa
a tecnologia do BDE. O dbExpress também foi desenhado para
ser altamente portátil e os drivers estão sendo feitos tanto para
Windows quanto para Linux. Esta nova arquitetura de driver
substitui a funcionalidade de acesso a dados do antigo BDE SQL
Links, mas sem o runtime e o desenvolvimento sobre o BDE.
Desta vez o dbExpress (que em breve será conhecido como
DataSnap Direct) é o driver recomendado para o acesso a base de
dados SQL Server no Delphi e no C++ Builder. Nós estaremos
deixando de utilizar a tecnologia BDE SQL Links em 2002 e
2003. Isto significa que não haverá mais nenhum
aprimoramento ou melhora no SQL Links em 2002.
O dbExpress foi desenhado com o objetivo de substituir o SQL
Links, portanto nós temos sustentado a migração e transição em
mente desde o principio. A arquitetura do desenvolvimento de
aplicações com base de dados em Delphi e C++ Builder foram
desenhadas para permitir diferentes tecnologias de acesso a
dados através da camada do Dataset. Neste design os drivers do
banco de dados, desde os componentes de desenvolvimento básico
e o código fonte semelhante àqueles da nova arquitetura dos
drivers, podem ser desenvolvidos sem quebrar o desenvolvimento
básico da aplicação. Isto permite que o mesmo modelo de
programação baseado em banco de dados, componentes visuais, e
DataSnap Middleware possam funcionar sem modificação.
Alguns esforços adicionais podem ser necessários para alguns
ajustes em uma aplicação que acessava o BDE em que algum
programador possa ter usado componentes SQL Links. Tudo isto
14
significa que, o esforço de transição do SQL Links para o
dbExpress foi desenhado para ser de baixo impacto e para a
maioria dos programadores precisará o mínimo de modificação
nos códigos.
Acesso a dados para tabelas locais
O próprio BDE, menos o SQL Links, foi primeiramente
desenhado para suportar tabelas locais Paradox e DBase. O
suporte do BDE às tabelas locais irá continuar. O suporte do
BDE a tabelas locais será marcado “frozen” nos novos releases
dos produtos em 2002. Isto significa que você continuará com as
tabelas locais suportadas pelo BDE, mas nenhum
aprimoramento será mais feito no BDE. O BDE para tabelas
locais continuará a ser suportado, mas você pode considerar que
ele está no estágio final e nenhuma nova característica será
acrescentada ou qualquer bug será corrigido. Enquanto isto não
acontece, a Borland recomenda que você migre as suas tabelas
Paradox e DBase para o Interbase 6 Desktop Edition. O utilitário
Datapump incluído no Delphi e no C++ Builder torna esta
transição mais rápida e simples. Uma vez as tabelas convertidas
para o InterBase, os programadores tem a opção de utilizar os
componentes Interbase Express (IBX) ou o dbExpress para
acesso as tabelas locais do Interbase.
Conclusão
A Borland tomou um grande cuidado ao tomar as decisões
sobre nova tecnologia, particularmente porque podiam afetar os
projetos já existentes ou em desenvolvimento de seus clientes.
Segundo a Borland, os planos para o dbExpress, BDE, e SQL
Links não poderiam ter sido desenvolvidos sem extensivo
feedback de seus clientes. A Borland diz apreciar o
relacionamento que temos com seus clientes e expressam a sua
gratidão para com os seus clientes pelo interesse e a participação
da comunidade de desenvolvimento neste esforço.
MeGAZINE
Delphi
Controlar Fidelização de
clientes no ECF
Por Claudenir C. Andrade
Pode parecer estranho, mas o ECF tem uma função
importante no controle e criação do sistema de fidelização de
cliente. Por quê? Porque toda fidelização está amarrada à compra
realizada ou a um serviço prestado. Por sua vez seu sistema de
retaguarda necessita ser alimentado por valores e pontos,
realizados e trocados em seu PDV.
O ECF é uma dessas ajudas que podemos ter para que este
controle possa ser contabilizado e emitido, sem a necessidade de
mais periféricos ou mais linhas de código adicionais ao programa.
/*Logo após solcitamos a impressão das informações da
pontuação do cliente*/
Bematech_FI_UsaComprovanteNaoFiscalVinculado(Pchar(‘Parabéns
por estar participando de nosso programa – Cliente fiel é Cliente
Feliz- Sua pontuação até o momento é : 870Pontos – Não perca
tempo e troque agora mesmo por mercadorias na boca do caixa
em que você foi atendido!!! 10 Pontos é igual a R$ 2,00; sua
pontuação equivale a 1.740 Reais!!!’));
Bematech_FI_FechaComprovanteNaoFiscalVinculado();
O uso de totalizadores não fiscais, aqui neste caso, é
fundamental. Podemos, por exemplo, criar um totalizador não
fiscal chamado “Fidelidade” e emitir para o cliente. Caso seja
solicitado ou caso esta opção seja default do software, o cupom de
fidelização indicando a quantidade de pontos e acompanhada de
mensagens promocionais para esta operação.
No começo do dia devemos cadastrar os totalizadores para
garantir a existência deles para que possam ser chamados desde
nossa aplicação.
/*Para nomear um totalizador não fiscal deve ser chamada a
função seguinte que como parâmetro necessita de um índice ou
código para esse totalizador e o nome que você deseja/*
Bematech_FI_NomeiaTotalizadorNaoSujeitoIcms
(12,Pchar(’Filedização’));
Para receber compras com a pontuação de seu programa
fidelidade, também não há mistérios. Basta informar a forma de
pagamento como sendo “Fidelidade” e pronto.
As vantagens da utilização dos contadores são as seguintes:
1) Todo processo fica vinculado ao ECF, como um
equipamento de Check com os dados do software.
2) Toda a pontuação emitida fica totalizada na impressora
fiscal.
3) Todo ponto trocado por produto também fica totalizado na
Forma de Pagamento.
No final do dia você tem todas essas variáveis impressas na
redução Z ou na leituraX que pode ser impressa a qualquer
momento na impressora fiscal, tornando o processo mais idôneo e
confiável.
Agora com o totalizador criado, podemos utilizá-lo para
creditar os pontos do cliente após a emissão do cupom e imprimir
um recibo para ele:
Bematech_FI_AbreComprovanteNaoFiscalVinculado
(Pchar(‘A Prazo’), Pchar(‘1000,00’), Pchar(‘00234’));
MeGAZINE
Claudenir é gerente de desenvolvimento de
software na Bematech e autor do livro “Automação
Comercial com C#, VB.NET e Delphi 6” lançado
pela Editora Érica – www.erica.com.br.
Ele também pode ser contatado pelo e-mail:
[email protected].
15
Delphi
DataSnap – Parte I
Por Anderson Haertel Rodrigues
Introdução
COM, OLE , DCOM, MTS, COM+, ActiveX, MSTDC, MMC,
Sockets, CORBA, ORB, Stub, Skelleton, SOAP, DSOM, Interface,
Stateless, Statefull, DCE, RPC, Stack, GUID, CLSID, IID, Early
Binding, Late Binding, Regra de negócios, etc.
UFA! Quanta palavrinha/sigla nova e bonita de ser falada.
Pode ter certeza que deixei de fora mais algumas dezenas de
siglas e palavras. Todas as siglas e palavras citadas acima estão
ligadas uma as outras, é claro, respeitando seus respectivos
fabricantes, os órgãos que as implementaram e as plataformas.
Para iniciar artigos sobre DataSnap “Objetos Distribuídos
(OD)”, não posso deixar de explicar o conceito por trás dessa
tecnologia, o porque a mesma existe e como usar. Fazendo assim,
sentido as siglas apresentadas acima.
Objetos
São entidades. Que manipulam e encapsulam informações,
possui um estado e dados, sendo que, posso modificar e obter
informações sobre o mesmo.
código para executar uma determinada tarefa, independente de
localização. Isto é, eles podem estar na mesma máquina (COM) e
ou máquinas distintas (DCOM, COM+).
Estou citando os protocolos da Microsoft® neste momento,
apenas para uma explicação mais ilustrativa. Veremos mais à
frente, o que é cada Sigla demonstrada e para que serve.
Antes de explicar os protocolos envolvidos no processo de
sistemas distribuídos, não posso deixar de citar que, as
Interfaces* é uma das almas do negócio, isto é, sem um bom
entendimento de Interfaces, você com certeza não entenderá e
não saberá implementar sistemas distribuídos.
É o passo inicial para que possamos ter sucesso nessa nova
empreitada. Mas, antes de iniciarmos na parte técnica, pretendo
demonstrar o conceito 3 Camadas (MultiCamadas), falar sobre
Client/Server a diferença entre os dois e as vantagens de 3
Camadas sobre Client/Server.
*Nota: Não se preocupem, demonstrarei o que é uma
Interface e como utilizá-la nos próximos capítulos.
Existem nos objetos:
A) Atributos - Que correspondem a um valor guardado no
objeto
B) Classificação - É o agrupamento de características
semelhantes.
C) Abstração, - Abstrair características de um objeto.
D) Encapsulamento - Muito parecido com a abstração, pois
permite, ocultar detalhes de implementação ao mundo exterior.
E) Entre outras características não menos importantes, mas,
está além do escopo desse artigo.
Objetos Distribuídos
São objetos conforme explicado acima, mas, armazenam
16
Objetos Distribuídos x Programação Orientada a Objetos
(OOP)
As duas estão intimamente ligadas. Não existem Objetos
Distribuídos sem OOP. Então, se por um acaso passou pela sua
cabeça em desenvolver sistemas distribuídos sem conhecer OOP,
sinto informar que não será possível. OOP lhe permite
desenvolver sistemas Orientado a Objetos, Objetos Distribuídos,
são os mesmos Objetos só que de forma Distribuída.
Não está nos objetivos desse artigo explicar e exemplificar
OOP. Apenas mencionei OOP para demonstrar ao leitor que OD
(Objetos Distribuídos) depende de OOP.
MeGAZINE
Delphi
Multi-Tier
É uma tecnologia que nos últimos anos vem sendo discutida,
falada, mas infelizmente poucos a estão implementando. O
Conceito de Multi-Camadas foi introduzido no Delphi 3, e veio
mesmo com força no Delphi 5, onde ganhou uma ABA chamada
MIDAS.
Middleware
É camada de software responsável pela abstração e
comunicação em alto nível, onde é ela que facilita a programação
distribuída.
Neste cenário temos:
DataSnap - “MIDAS”
No Delphi 6, o MIDAS mudou de nome! Passando a se
chamar: DataSnap, onde na realidade, DataSnap é o MIDAS com
suporte a SOAP/XML HTTP. Então, daqui para frente, não
devemos mais chamar de MIDAS e sim, DataSnap, conforme a
Borland®.
As Camadas
Quando falamos em desenvolvimento em camadas, nos
referimos a um modelo de programação que prevê a divisão do
programa em 3 e ou mais partes bem definidas e distintas:
- Interface - A tela no lado Cliente/Estação Cliente – Não
confundir com Interfaces;
- Regras de Negócio - Definição de regras na camada do
meio; “falando em português bem claro”;
- Aqui ainda existe a dúvida do servidor de Aplicação.
Servidor de Aplicação é uma máquina/computador físico, isto é, é
outro computador o responsável pelo processamento das regras.
- Banco de Dados
Neste cenário, foi apresentada a clássica arquitetura 3
Camadas. Mas, por que alguns autores falam em n-Camadas e
ou Multi-Camadas?
R: O fato se dá que, nada me impede de criar uma camada
auxiliadora no desenvolvimento do meu sistema. Isto é, posso ter
uma camada de conexão ativa com o Banco de Dados, escrita
dentro do Objeto, onde meus vários módulos não necessitam criar
a sua própria camada de conexão. Esses módulos chamam e se
conectam no Banco de Dados, utilizando a nossa camada
Auxiliadora. Pronto, já temos a 4ª camada! E a Quinta, a Sexta?
- Tudo depende da sua necessidade e imaginação.
Quando falamos em 3 Camadas, alguns perguntarão:
Se existem 3 Camadas, existiu algum dia 2 Camadas? 1
Camada?
R: Sim. Existiu. E existe 2 Camadas, 1 Camada.
1 Camadas eram os famosos Mainframes. Onde a
arquitetura é Uniprocessada.
2 Camadas, é o que hoje conhecemos como: Client/Server.
Client/Server x MultiCamadas
Muitos se perguntam o por que do surgimento da tecnologia
Multi-Camadas? Poxa, estava quieto no meu canto “feliz” com o
meu Client/Server e agora todo o mundo (inclusive eu é claro!)
fala na maravilha das 3 Camadas (Multi-Camadas). Então, por
que necessito migrar e quais as vantagens que as “Camadas”
trazem para os meus sistemas?
R. Você não é obrigado a mudar sua aplicação Client/Server
para Multi-Camadas. Se você está feliz, está tudo certo e com boa
performance. Não mude!
Agora, se você já se deparou com algum desses problemas
apresentados abaixo, você é um sério candidato a pensar
seriamente na mudança do seu sistema.
As desvantagens do Client/Server
- Dispersão das regras - Quando trabalhamos com os eventos
de componentes visuais é fácil dispersarmos as regras, tais como
associarmos consistência de campo ao evento OnExit do TDBEdit
em um momento e ao evento OnValidate do TField em outro
momento. Obviamente isso causa dores de cabeça no momento da
manutenção.
- Dificuldade de distribuição – Sempre que uma regra é
alterada o programa tem que ser re-distribuído, trazendo
problemas de controle de versão e distribuição física do aplicativo
e seus complementos.
- Regras junto dos dados - Ao colocarmos as regras dentro do
banco de dados, usando os recursos nativos do banco de dados
(triggers, stored procedures e constraints), estamos
automaticamente ligando nossa aplicação ao banco de dados que
estiver sendo usado, aumentando em muito o re-trabalho, caso a
aplicação venha a ser convertida para ser usada com outro banco
de dados.
- Queda de performance – A queda de performance no
servidor, pode ser facilmente conseguida com o acúmulo de
regras e ou constraints que este deve verificar e processar. Não é
difícil encontrarmos adeptos do: Tudo fica no servidor! Ok. Para
isso teremos de ter um servidor de Banco de Dados dedicado e
extremamente potente para o mesmo não perder a sua
performance, e mesmo assim, pode ser que você se depare com a
perda de performance. Não pense que a perda de performance
será visível quando houver 10, 15 máquinas no ar. Ela deve
aparecer quando houver mais de 50, 100, 300 1000.... máquinas
acessando o seu sistema.
Isso ocorre com o famoso “gargalo de rede”. Neste momento,
não adianta melhorarmos o hardware do servidor, melhorarmos
as nossas maquinas clientes, uma rede mais veloz...... ainda
assim, podemos nos deparar com o problema de gargalo de I/O da
máquina servidora.
MeGAZINE
17
Delphi
Figura 1: Arquitetura Cliente/Servidor
As Vantagens do MultiTier
você desenvolve sistemas baseado em Multi-Camadas, você
necessita modificar apenas um .EXE e ou uma DLL que se
encontra no servidor de Aplicação. Fazendo isso, todas as estações
já enxergarão a nova regra de negócio ou a regra de negócio
modificada.
Transforme todas as desvantagens do Client/Server em
vantagens para MultiTier. Mas como?
- A não dispersão das regras - As regras de negócios estão e
devem estar todas no mesmo lugar, isto é, na camada de meio.
Não importando o tipo da regra. Desde uma regra para atualizar
o valor das contas a receber as mais complexas, como:
o Atualizar nota;
o Baixar estoque;
o Gerar financeiro;
o Gerar Contabilidade;
o Gerar Escrita Fiscal;
o Atualizar Patrimônio;
§ Todos esses processos de atualização podem ter regras de
consistência, regras de analise e várias outras necessidades
específicas do seu cliente.
Todas no mesmo lugar!
- Não existe dificuldade de distribuição – Por que? Quando
18
É claro, estamos falando em regras de negócios, se você
modificar a tela de apresentação, você necessitará atualizar seus
.EXE´s clientes que se encontram na rede. Existe uma solução
elegante para esse “problema”, conhecida como Lançador de
Aplicativos, mas a explicação dessa técnica foge do escopo do
nosso artigo.
- As Regras não ficam junto dos dados – Boa parte da
explicação já foi dada no tópico 2, mas imaginemos o seguinte:
Você precisa criar uma numeração automática para um cadastro
em especifico. Se fossemos utilizar recursos de um Banco,
poderíamos facilmente criar uma Trigger com um Generator
para o InterBase, Criar uma coluna IDENTITY para o SQLServer e as SEQUENCE´s para o Oracle. Vejam que aqui eu
“casei” minha aplicação com um Banco de Dados?! Podemos e
devemos evitar isso em MultiTier, onde criaremos uma regra de
negócios baseada na linguagem SQL-Ansi para contornarmos o
problema.
MeGAZINE
Delphi
- A Queda de Performance é contornada – Como? Load
Balance e Serialização de Servidores! Em MultiTier, podemos ter
a tarefa do servidor divida entre várias máquinas na rede.
Podemos ter a mesma regra divida entre vários servidores,
quando um servidor ficar sobre-carregado, entra em cena outro
servidor de aplicação para auxiliar o processamento de alguma
regra, e, se um servidor “X” cair, entra em cena o servidor “Y”.
Vimos nos dois exemplos citados, o Load-Balance e a Serialização.
Podemos ainda, ter regras separadas, isto é, regra de Vendas
separadas das regras de Compras.
Sendo que, estão sem servidores diferentes, e desta forma,
com certeza não teremos o problema de gargalo de rede e queda
acentuada de performance.
- Independência de Localização: - O sistema construído em
Multi-Camadas, fica livre da localização fixa do servidor de
Aplicação. Na verdade, em se falando de Delphi, nada me impede
de fixar o nome do Servidor de Aplicação nos componentes
SimpleObjectBroker* e ou no DCOMConnection*, mas eu
pessoalmente sou adepto da independência total de localização**.
*Nota: Os componentes citados serão explicados nos próximos
artigos.
**Nota: Quando formos distribuir nosso aplicativo, eu irei
demonstrar as duas técnicas, a de localização física usando os
componentes citados e a independência de localização usando o
MSIEXEC.EXE.
Figura 2: Arquitetura MultiTier
MeGAZINE
19
Delphi
Explicação Geral da Figura 2
Conclusão
Por se tratar uma figura que ao primeiro contato pode se
parecer estranha, resolvi comentar a mesma. Temos a estação
servidora de Banco no topo, na camada do meio o nosso
DataSnap fazendo a ponte entre o servidor de Banco de Dados e
os protocolos COM/DCOM/MTS/COM+/CORBA, etc.
As estações se conectam a camada do meio, onde se
encontram as regras, a camada de meio se conecta ao Servidor de
Banco de Dados e estações - Thin Client, isto é, é uma via de duas
mãos, o servidor de Banco sempre conversará com a camada de
negócios, a camada de negócios, sempre conversará com o
Servidor de Banco e com as estações e, as estações conversam
com a Camada de meio.
Não deve ser quebrado esquema de comunicação!
Os que prestaram atenção na figura, viram que existem
setas ligando a mesma máquina/estação a objetos diferentes. É
com essa técnica que conseguimos deixar os servidores
descarregados para processamento, e ainda utilizarmos por nós
mesmos a técnica de Load-Balance. Também demonstrei na
figura, que maquinas Client´s podem ser Servidoras e Client´s ao
mesmo tempo. Como isso acontece?
R: É possível transformar uma máquina client com um
poder de processamento bom em servidor e Client. Ela é Cliente
do esquema mostrado acima, mas, pode servir de Servidora, onde
nela pode ter um ou mais objeto(s) COM+/CORBA instalado(s)
para servir a outras máquinas Client´s e ou servidoras, e assim
sucessivamente.
Temos nesse cenário a arquitetura Objetos Distribuídos!
20
Tentei demonstrar nesse 1o artigo, o que é, como funciona e
para que serve a arquitetura Multi-Camadas e ainda
demonstrar Objetos Distribuídos. Com o crescimento constante
da WEB, faz-se necessário o entendimento e o desenvolvimento
de aplicações distribuídas. É um salto tecnológico grande. A
informática está em constante crescimento na procura de novas
soluções para os nossos problemas. Multi-Camadas é a evolução
do Client/Server. Também usei o termo – 3 Camadas – apenas
para exemplificar de uma forma melhor a tecnologia para o
leitor, mas, o Delphi não nos impõem nenhuma limitação para a
utilização de quantas camadas quisermos usar. Por isso, sempre
tentei utilizar a palavra: Multi-Camadas.
No próximo artigo, veremos os famosos: COM/OLE/DCOM/
MTS/COM+/CORBA/Socket´s, HTTP e SOAP
Sucesso e Saúde a todos!
Um Abraço.
Anderson Haertel Rodrigues
Consultor em desenvolvimento de Sistemas Client/
Server - MultiCamadas/DataSnap.
Oferece treinamentos para empresas em:
InterBase, SQL-Server, Delphi e COM+
[email protected] - [email protected].
Florianópolis - Santa Catarina - Brasil.
MeGAZINE
Palm
LFTP
Autor: Marcio Alexandroni da Silva
LFTP é um aplicativo gratuito de cliente FTP. Com ele,
enviar e receber dados de servidores FTP é uma tarefa simples e
automatizada, já que suporta scripts pré-configurados, onde o
usuário apenas precisará selecionar qual script utilizar e a
conexão e execução dos comandos será automática.
Além de simples e de fácil utilização, o LFTP suporta cartões
de expansão de memória para somente enviar aplicações e bancos
de dados armazenados no cartão.
O LFTP está disponível no site de busca para aplicativos
PalmOS, www.palmgear.com .
Através desta tela de configuração, os processos de conexão a
um servidor FTP e execução de comandos de transferência de
bancos de dados e aplicações ficam muito simples.
Note no canto inferior direito da tela os números 1 a 5 que
são as cinco configurações de servidor possíveis. As configurações
são:
· Server: Endereço IP do servidor. Se o servidor FTP não
utilizar uma porta padrão, adicione o número da porta depois de
um espaço.
· Login: Nome de Login no servidor.
Configuração do LFTP
As configurações do LFTP são feitas através do menu Misc/
Preferences:
· Password: Senha de acesso ao servidor FTP.
· Use scripted cmds: Quando a opção Use Prefs está marcada,
usando esta configuração executa automaticamente o script após
a conexão ao servidor FTP.
· No PASV: Seleciona modo “transfert PASV”, segundo o
autor.
· As linhas são o local onde os comandos serão colocados.
· Use Prefs: Se marcado, o Login e Senha serão enviados ao
servidor assim que a conexão for efetuada.
Se estiver desmarcado, o usuário terá que informar o Login e
Senha.
Utilização do LFTP
Para conectar a um servidor basta entrar no menu
Utility e selecionar qual configuração utilizar.
MeGAZINE
21
Palm
· ldir: Lista os bancos de dados no Palm.
· put <Nome>: Envia um Banco de Dados ou aplicação para o
servidor. Não é necessário acrescentar a extensão e o Nome é
“Case Sensitive”.
· get <Nome.extensão>: Recebe um Banco de Dados ou
aplicação do servidor. É necessário acrescentar a extensão .pdb
ou .prc e o nome é “Case Sensitive”.
· ldirfs [Diretório]: Lista os arquivos no cartão de expansão.
· putfs <Diretório/Arquivo>: Envia o arquivo do cartão de
expansão para o servidor. É necessário informar o caminho
completo, ex: putfs /DCIM/100MSDCF/DSC00001.
Durante a transferência, o LFTP mostra pontos que são
correspondentes a registros ou resource.
Resumo dos Comandos do LFTP
· pwd: Informa o diretório atual no servidor.
· cd <diretório>: Muda o diretório no servidor.
· mkd <diretório>: Cria o diretório no servidor.
· rmd <diretório>: Remove o diretório do servidor.
· del <arquivo>: Apaga o arquivo do servidor.
· dir: Lista os arquivos no servidor.
22
Observação sobre o LFTP: O usuário do Palm pode não saber
quando houve algum problema de transmissão de bancos de
dados entre o Palm e o servidor FTP. É recomendado que você
crie arquivos de controle que são enviados/recebidos por último.
Sua aplicação em ambos os lados deve testar se o arquivo de
controle chegou. Se chegou, significa que a transferência foi
completa, senão, houve algum problema com a transferência.
Marcio Alexandroni atua no desenvolvimento de sistemas
utilizando tecnologias Oracle™, Delphi™, Linux e Palm™.
Começou a trabalhar na plataforma PalmOS no início de 1999 e
hoje utiliza as ferramentas CodeWarrior, Falch.net, NSBasic e
PocketStudio.
MeGAZINE
Delphi
Traduzindo as Mensagens do
Delphi via Translation Manager
Por Alessandro Ferreira – Suporte Técnico The Club
[email protected]
Neste artigo iremos mostrar como traduzir para o português
as mensagens de erros apresentadas durante a execução de uma
aplicação, utilizando a ferramenta “Translation Manager”
disponível no Delphi.
Para exemplificar, criaremos um simples projeto para
simular alguns erros de conversão onde as mensagens de erro,
por padrão virão em inglês.
Com isso, quando executarmos a aplicação iremos receber as
mensagens de erro:
Figura 2
Figura 3
figura 1
Data Inválida: StrToDate(‘a’);
Float Inválido: StrToFloat(‘m’);
Integer Inválido: StrToInt(‘i’);
Figura 4
MeGAZINE
23
Delphi
Para o usuário final ou mesmo por uma questão de estética
de nossa aplicação, não fica bem ter mensagens em inglês e
português, principalmente porque mesmo com as mensagens em
português o cliente apenas irá ligar e dizer “que o programa deu
pau”, imagine em inglês!
Como traduzir?
Felizmente o Delphi oferece uma ótima ferramenta para
tradução das mensagens que fica disponível no menu “Project” |
“Languages”, vamos por em prática.
Importante: Salve seu projeto antes de acessar o “Translation
Manager”.
Selecione o menu “Project” | “Languages” | “Add” (Figura 5).
Figura 7
Agora clique em “Finish” e responda “Yes” na caixa de
confirmação que pede para compilar o projeto que irá ser
responsável pela tradução. (Figura 8).
Figura 5
Observe que nosso projeto já estará selecionado, apenas clique
em “Next”.
Agora selecione a linguagem, que obviamente em nosso caso
será “Português (Brazil)” (Figura 6).
Figura 8
Após a compilação, será mostrada um Form contendo as
estatísticas da compilação, conforme mostra a figura 9:
Figura 9
Figura 6
Clique em “Next”, até chegar no Form mostrado na Figura 7.
24
Tecle OK e automaticamente será solicitado para salvarmos o
projeto referente a tradução onde é sugerido uma pasta com o
MeGAZINE
Delphi
Figura 10
nome “PTB” que é a abreviação de
“Português Brazil”, dentro da pasta
principal de nosso projeto, apenas
aceite as sugestões para
prosseguirmos.
Traduzindo as mensagens.
Após salvarmos o projeto, nos
será apresentada a ferramenta
“Translation Manager”, como
mostra a figura 10.
Primeiro, deveremos ativar a
linguagem teclando “ALT+S” e
escolhendo “Portuguese (Brazil)”. O
próximo passo é localizar as
mensagens que desejamos traduzir,
para isso tecle “CTRL+F” e digite a
mensagem na caixa como mostra a
figura 11.
A mensagem será localizada na
lista de mensagens e relacionado na
janela de “Results”, bastando
darmos um duplo clique sobre a
mesma para que seja posicionada
Figura 11
MeGAZINE
25
Delphi
na lista de mensagens e finalmente traduzi-las, conforme mostra
a figura 12:
Figura 12
Repita os passos acima para as demais mensagens que deseje
traduzir e ao término tecle “CTRL+S” para salvar suas
alterações.
Figura 13
Feche o “Translation Manager” e abra o projeto de tradução
que deverá estar disponível na pasta “PTB” dentro da pasta
principal de seu projeto, teclando “CTRL+F9”.
Após compilar o projeto de tradução, abra o projeto principal e
no menu “Project” | “Languages” | Set Active e certifique-se de
estar “Portuguese (Brazil) “.
Figura 14
Agora, compile e execute seu projeto e verá as mensagens
traduzidas, conforme mostram as figuras 13, 14 e 15.
Conclusão
Existem vários artifícios que podemos utilizar para traduzir
as mensagens que serão apresentadas à nossos usuários finais.
Figura 15
26
O “Translation Manager” sem dúvidas é uma forma
bastante prática e elegante com o qual podemos obter ótimos
resultados. O projeto de exemplo referente esta matéria está
disponível para download em nosso site no endereço
www.theclub.com.br/revista/langptb.zip, até a próxima.
MeGAZINE
Perguntas & Respostas
Pergunta: Gostaria de utilizar o objeto InputBox para
receber uma senha qualquer em minha aplicação, porém ao
digitar o valor quero que apareça asteriscos, assim como posso
configurar na propriedade PassworrChar de um TEdit. Isso é
possível?
Resposta: Olhando a primeira vista não! Porém, é possível
fazer alguns tratamento via mensagens do Windows e conseguir
implementar uma rotina para mostrar um “PasswordChar” no
TEdit contido no InpuBox, veja abaixo o código:
const
InputBoxMessage = WM_USER + 123;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
procedure InputBoxSetPasswordChar
(var Msg: TMessage); message InputBoxMessage;
public
{ Public declarations }
end;
var
Form1: TForm1;
{$R *.DFM}
procedure TForm1.InputBoxSetPasswordChar
(var Msg: TMessage);
var
hInputForm, hEdit, hButton: HWND;
begin
hInputForm := Screen.Forms[0].Handle;
if (hInputForm <> 0) then
begin
hEdit := FindWindowEx
(hInputForm, 0, ‘TEdit’, nil);
SendMessage
(hEdit, EM_SETPASSWORDCHAR, Ord(‘*’), 0);
end;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
InputString: string;
begin
PostMessage(Handle, InputBoxMessage, 0, 0);
InputString := InputBox
(‘The Club’, ‘Digite a senha’, ‘’);
if InputString <> ‘’ then
ShowMessage(‘Retorno do InputBox ‘ +
InputString);
end;
Dúvida enviada por Alessandro F. dos Porcos - Taguaí - SP
implementation
MeGAZINE
27
Perguntas & Respostas
Pergunta: Gostaria de saber como fazer um “Sort” em uma
StringList, porém em ordem descendente.
Resposta: Isso é possível, porém através do método
“CustomSort” do TStringList, o qual possibilita fazer uma
ordenação customizada no objeto. Veja abaixo um simples
exemplo:
// função para customização da ordenação.
function CustomizeSort(List: TStringList; Index1,
Index2: Integer): Integer;
begin
if List[Index1] < List[Index2] then
Result := 1
else if List[Index1] > List[Index2] then
Result := -1
else
Result := 0;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
Lista: TStringList;
begin
Lista := TStringList.Create;
// cria lista.
try
Lista.Assign(ListBox1.Items); // pega os itens
// do ListBox.
Lista.CustomSort(CustomizeSort); // executa um
// CustomSort.
ListBox1.Items.Assign(Lista);
// devolve os
// item ordenados.
finally
Lista.Free;
// libera lista.
end;
end;
Dúvida enviada por Álcool Ferreira S/A, Osasco/SP.
Pergunta: Preciso efetuar uma consulta com o operador IN,
porém necessitaria que o subconjunto fosse um parâmetro e a
SQL não aceita que o subconjunto seja um parâmetro, como
posso implementar?
END
END
Ao informar o parâmetro “Pesq”, utilize:
SP,RJ,PR
Separando os valores por vírgula ou outro caractere
qualquer.
Dúvida enviada por Total Informática Ltda, Feira de
Santana/BA.
Pergunta: Estou utilizando FireBird e IBDataSet para
acesso a dados. Ao selecionar os dados gostaria de apenas exibilos em DBEdits mas sem deixar o usuário poder alterar, até que o
IBDataSet seja colocado em modo de edição.
Qual seria a melhor solução?
Resposta: Existem várias alternativas, uma delas seria
alterar a propriedade “AutoEdit” do componente DataSource ao
qual seus DBEdits estão ligados para “False”.
Com isso, não será permitida edição até que o TDataSet seja
colocado em modo de “Insert” ou “Edit” implicitamente.
Resposta: Realmente não é possível passar este
subconjunto como parâmetro para ser utilizado diretamente com
uma cláusula IN, porém é possível implementar utilizando a
cláusula LIKE. Veja o exemplo:
28
CREATE PROCEDURE “sp_cadteste_in”
(
Pesq VarChar(30)
)
RETURNS (
CODIGO INTEGER,
NOME VARCHAR(20) CHARACTER SET NONE,
CIDADE CHAR(20) CHARACTER SET NONE,
VALOR NUMERIC(3,3),
ATIVO SMALLINT,
UF VARCHAR(2) CHARACTER SET NONE)
AS
BEGIN
FOR SELECT CODIGO,NOME,CIDADE,VALOR,ATIVO,UF
FROM CADTESTE WHERE :Pesq Like ‘%’ || UF || ‘%’
INTO :CODIGO,:NOME,:CIDADE,:VALOR,:ATIVO,:UF
DO
BEGIN
SUSPEND;
Dúvida enviada por Infocompus Informática e Tecnologia
Ltda, Amargosa/BA.
MeGAZINE
Perguntas & Respostas
Pergunta: Existe como, através de SQL, selecionar os
registros em “Cachê” em um ClientDataSet? Como?
Resposta: Para acessar os dados que estão em “cache” em
um ClientDataSet, bastará acessar o “Delta” do mesmo que
TODAS as informações pendentes estarão disponíveis!. Veja
abaixo um simples exemplo, onde alimentamos um novo
ClientDataSet somentes com as “pendencias” de outro:
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
if ClientDataSet1.ChangeCount > 0 then
begin
ClientDataSet2.Data := ClientDataSet1.Delta;
ClientDataSet2.Open;
end;
end;
Dúvida enviada por Valdir Alberto Dill, Santa Helena/PR.
Pergunta: Em um formulário tenho um Edit e um Memo.
O Memo constantemente recebe textos e isso faz com que a barra
vertical vá andando automaticamente para baixo, mas o usuário
pode ir dentro do Memo e ir subindo para ver as linhas
superiores. Como posso fazer para que quando o foco estiver no
Edit e o usuário teclar seta para baixo, posicionar o Memo na
última linha sem tirar o foco do Edit?
Resposta: Poderá enviar uma mensagem ao TMemo
utilizando o evento onKeyDown do Edit, veja o simples exemplo
abaixo:
procedure TForm1.Edit1KeyDown
(Sender: TObject; var Key: Word;
Shift: TShiftState);
begin
if Key = vk_Down then
Memo1.Perform(EM_LineScroll, 0,
Memo1.Lines.Count-1);
end;
Dúvida enviada Infomaster Soluções em Informática Ltda,
Santo André/SP.
Pergunta: Como faço para simular o pressionamento da
tecla “PageDown” em um componente DBGrid sem estar com o
foco nele?
Resposta: Poderá utilizar o método “Perform” do DBGrid
MeGAZINE
enviando uma mensagem ao mesmo, veja abaixo um simples
exemplo:
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
DBGrid1.Perform(wm_KeyDown, vk_next, 0);
end;
Dúvida enviada por Edson Murilo Maestri, BLumenau/SC.
Pergunta: Gostaria de conectar ao registro do Windows de
uma máquina da rede através de seu IP (Preferencial) ou pelo
seu nome, como proceder?
Resposta: Poderá acessar através do método
RegistryConnect do objeto TRegistry, veja o exemplo abaixo:
// O usuário que for acessar tem que ter permissão na
máquina remota.
implementation
uses Registry;
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var
R: TRegistry;
S: TStringList;
begin
R := TRegistry.Create;
S := TStringList.Create;
Button1.Enabled := not Button1.Enabled;
try
R.RootKey := HKEY_LOCAL_MACHINE;
if R.RegistryConnect(‘\\SERVIDOR’) then
begin
R.OpenKeyReadOnly(‘\SOFTWARE\TheClub’);
R.GetKeyNames(S);
Memo1.Lines.Assign(S);
end
else
ShowMessage(‘Não foi possível
conectar ao Registrador!’);
finally
S.Free;
R.Free;
Button1.Enabled := not Button1.Enabled;
end;
end;
29
Perguntas & Respostas
Funciona sem problemas, PORÉM, existe a necessidade de
dar permissão ao usuário que poderá fazer acesso ao “Registry”
da máquina remota, caso contrário não irá funcionar.
Dúvida enviada por APP Processamento de Dados S/C Ltda,
S.J.Rio Preto/SP.
ADOConnection por exemplo. Existem drivers OLEDB freewares
na Internet, poderá baixar em:
http://www.ibphoenix.com
http://www.oledb.net
Nos sites acima, além do driver para ser instalado,
encontrará exemplo da String de conexão à ser utilizada no
componente ADOConnection.
Pergunta: Porque a rotina abaixo está dando o erro
“Unassigned Code”?
Não temos uma comparação entre ADO e IBExpress para lhe
fornecer, porém o IBExpress faz acesso nativo diretamente ao
Interbase via APIs do mesmo, aproveitando dessa forma melhor
os recursos oferecidos pelo Interbase, ao passo que a conexão
através do ADO irá necessitar de um drive externo, como os
citados acima, basicamente sendo este o diferencial entre as duas
formas de conexão.
Var
VDAta : TDAte;
begin
VData := Date;
SQLDSSaldoCaixa.Close;
SQLDSSaldoCaixa.CommandText := ‘Select * from
SALDOCAIXA Where DATA>=:VDia’;
SQLDSSaldoCaixa.Params[0].asDateTime := VData;
SQLDSSaldoCaixa.Open;
end;
Dúvida enviada por Kleber Luis Marioti, Catanduva/SP.
Resposta: No caso do “CommandText” via programação
deve ser feita a criação do parâmetro “a mão”!. Veja abaixo um
simples exemplo:
var
VData : TDate;
begin
VData := StrToDate(’05/03/1991');
cdsTeste.Close;
cdsTeste.Params.CreateParam(ftDate,
‘p’, ptInput).AsDate := vData;
cdsTeste.CommandText := ‘Select *
From Sales where Ship_Date = :p’;
cdsTeste.Open;
end;
Pergunta: Como eu faço para que um laço de repetição “for”
incremente de dois em dois.
Resposta: Isso não é possível na estruturação do “FOR” do
Delphi, o incremento é feito automaticamente pelo laço de
repetição e sempre é de um em um mesmo! Nesta situação
poderá utilizar um laço “While”, como por exemplo:
Dessa forma o parâmetro será reconhecido sem problemas.
var
i: integer;
begin
i := 0;
while (i <= 10) do
begin
// suas instruções.
i := i + 2;
end;
end;
Dúvida enviada por Almir Rodrigues Borges, Araçatuba/SP.
Dúvida enviada por Marco Batista, Marília/SP.
Pergunta: Gostaria de saber como eu faço para utilizar o
ADO com o Interbase? Gostaria de saber também se existe
alguma desvantagem em utilizar o ADO ao IBExpress.
Envie-nos suas dúvidas, dicas e exemplos
Resposta: Para acessar o Interbase através do ADO será
necessário um driver OLEDB para fazer o acesso! Tendo este
driver instalado em sua máquina bastará criar a conexão via
e-mail: [email protected]
30
MeGAZINE
para que possamos publicá-las.