>Já fiz alguns testes com o SQL Server, mas agora preciso ir adiante. Comprei o livro "SQL Server 2000 - Administração e Desevolvimento" - É muito bom, mas minhas dúvidas (são muitas!!!) são em relação ao uso do SQL com o VFP utilizando CursorAdapters com ODBC:
>
>
>Poucos Registros
>Atualmente, quando o usuário entra no formulário de clientes, eu abro uma grade com todos os clientes. Então ele se movimenta na grade e pressiona ENTER para abrir a ficha daquele determinado registro.
>Sei que não posso fazer isto usando SQL, pois preciso filtrar alguns registros. Como posso criar uma interface eficiente usando SQL? Pensei em filtrar pelo Nome ou CNPJ do cliente.
>
R: Pessoalmente eu uso um botão ao lado do campo ou um botão generico onde eu permito que o usuário escolha o tipo de dado que deseja pesquisar daquela tabela.
Crie um form generico a ser chamado por uma classe de botão, e permita que o usuário selecionar o campo no qual deseja fazer a pesquisa, monte um comando SELECT no VFP e envie ao SQL, se houver resultado, exiba em uma grade no mesmo form.
( limite o numero de campos a exibir na grade ) para que o usuário selecione o registro desejado.
retorne o codigo unico do registro deste form de pesquisa e chame pelo CA...p/ retornar os dados
do registro desejado.

>
>Tipo de Dados
>No DBC eu uso apenas 3 tipos de dados: Caracter, Numerico e Data. Para campos lógicos, utilizo a estrutura Numeric (0 = falso, 1 = verdadeiro). Vi que no SQL, temos vários tipos. Posso continuar usando esses mesmos 3 tipos ou é melhor utilizar um campo específico (questão de performance, segurança, normalização). Vou mostrar alguns exemplos que uso em VFP e gostaria de sugestões para converte-los no SQL:
>Nome - Caracter 50
>Sexo - Caracter 1 (M ou F)
>Inativo - Numerico 1 (0=Ativo, 1=Inativo)
>Quantidade - Numerico 7 (de +999999 a -999999)
>Valor Unitário - Numerico 12,3
>Aniversário - Data 8
>
R: a unica coisa que muda é que no SQL Server vc deve escolher Smalldatetime ou Datetime.
Se seu sistema precisar de datas apos o dia 6 junho 2079 vá para Datetime do contrario fique
com o Smalldatetime, pois ocupa menos espaço em disco e a performance é melhor.
Faça o CA transformar tudo em campo tipo Date automaticamente para vc no frontend.
( logico no SQL é BIT )

>
>Chave Primária
>No DBC eu tenho um campo INTEGER que é sequencial. Tenho uma função que trava o registro, soma mais 1 no último e atualiza a chave primária do registro.
>No SQL Server, vi que posso utilizar um campo IDENTITY ou GUID. As vantagens do IDENTITY é ser gerado automaticamente e ocupar menos espaço no banco. O GUID deve ser gerado através de uma função e ocupa mais espaço no banco, porém é único e pode ser muito útil para replicação.
>
R: Esquece GUID, é extremamente pesado, não compensa e o desempenho é até 30x mais lento que com Identity ( vi a tabela de comparação em testes ) vc pode criar chaves compostas para replicar que são mais eficientes.
GUID só é bom para um sistema pesado, com necessidade absoluta de unicidade de valor entre varios servidores para uma grande base de dados centenas de GB por tabela.

>
>Página de caracteres
>Como ficam os acentos no SQL Server? No DBC eu uso SET COLLATE TO "GENERAL". No SQL tem alguma coisa parecida?
>Além disso, se eu for pesquisar JOÃO e no banco de dados estiver JOAO, o SQL reconhece isso?
>
R: O padrão nosso é Latin1_General_CI_AS onde CI significa Caracter Insessitive ( não importa se a letra é maiuscula ou minuscula )
Joao = JOAO na pesquisa

AS significa Accent Sensitive ( acento afeta a pesquisa ) troque por AI se quiser que Jõao = Joao
Veja no BOL (books on line)

>
>Índices
>Os índices podem ser Clustered ou Non-Clustered. Vale a pena usar o índice Clustered?
>
R: Muito, pois a pesquisa se torna instantanea, isto é a tabela segue a ordem do indice (fisicamente)
Escolha bem o indice que vale a pena ( Muito !!! )

>
>Log de Transação
>Utilizando os triggers, eu construi uma rotina de auditoria em DBC. Vi que o SQL tem um recurso nativo. Funciona bem? Compromete a performance?
>
R: O log de transação deve sempre ficar em um HD separado do arquivo de dados, pois se um HD pifa vc ainda tem outro.
Deixar no mesmo HD afeta a performance, pois o arquivo de log deve ser salvo e depois ocorre a alteração na tabela de dados.
O arquivo de log é um script que diz o que foi feito ( mudança na tabela ) antes de ser feita a mudança fisica, é uma forma de segurança.
O log de transação é usado apenas para recuperar dados.
LOG de transação (historico) que informa as mudanças que cada usuário faz deve ser feito como no VFP, veja 2 tabelas DELETED e INSERTED no help do BOL.

>
>Begin Transaction / Commit
>Funciona bem com Cursor Adapter?
>
R: Sim, defina a transação como sendo manual no VFP e se tudo tiver OK de um SQLCommit no final.

>
>Replicação / Backup / "Reindex"
>Vou utilizar as ferramentas do próprio SQL Server, ok? Alguma recomendação?
>
R: Estude as diferentes formas de backup que existem e as diferentes formas de Restore, cada uma tem uma razão diferente de ser.
Reindexar, só se o desempenho for muito baixo e a alteração / inclusão for muito elevada.
Normalmente não é necessário pois o SQL Server tem uma ferramenta que faz a atualização estatistica dos indices para mantere a performance elevada nas pesquisas.
Não pense mais em registros e indices, mas sim em paginas de dados e indices.
Replicação, não fiz e geralmente vc coloca um DBA para fazer este serviço.
(estes assuntos são complexos)
Se desejar faça somente um bakcup full e um restore full para simplificar.
Use SQL-DMO via VFP p/ fazer backup e restore ou use o enterprise manger para fazer.
veja exemplo no help do CD do SQL Server p/ VB

>
>Instalação do SQL Server
>A idéia inicial era ter o mesmo sistema acessando DBC e SQL através do Cursor Adapter. Teria apenas um sistema e o usuário escolheria o banco de dados. Mas acho que usando apenas o SQL Server, vou ter um produto final muito mais estável e eficiente.
>Porém, este produto será instalado em pequenos clientes. Uma máquina apenas, rodando Windows 98, funcionaria com o SQL Server? (neste caso estou pensando em usar o SQL Express...)
>
R: Em win 98 use MSDE ( é Free ) ( deve ser em redes pequenas ) vc pode ter mais de 100 conexões, mas só pode executar 5 tarefas simultaneamente, mais que isso o MSDE coloca um pedagio ( pedagio neste caso é demorar até 30 seg. para retornar os dados )
Tarefas são Stored Procedures, comandos SELECT, comandos DMO, etc...
Só afeta se muitos usuários executarem comandos do frontend no servidor SIMULTANEAMENTE.
Funciona em redes até 50 estações, só não vale para redes de telemktg, onde o uso da base de dados é intensivo.
Memoria e HD's separados afetem muito a performance.
Fique com um só tipo (DBF ou MDF), ter 2 complica as coisas e só dá mais trabalho.

>
>Criar / Atualizar Banco de Dados
>Para criar o banco de dados no SQL Server não seria problema... E a atualização da base dos clientes, como pode ser feita?
>
R: Vc pode atualizar a base de dados remotamente via conexão ADSL, etc... usando o enterprise manager do SQL server ou qq. ferramenta de 3os. Criar vc pode via Script e ou enterprise manager.

>
>Tabelas que não mudam no cliente
>Li um artigo que dizia ser uma boa prática manter tabelas que não mudam na máquina local. Ex: Estados.DBF - Algum comentário a respeito?
>
R: Prefiro a abordagem de baixar os dados que não mudam na inicialização do sistema.
Os usuários aceitam que os sistemas demorem no inicio.
(mantenha todos os dados em um unico lugar)

>
>
>Integridade
>Uso o DBC "completo" - Tenho triggers, regras de registro, índices candidatos, etc. No meu sistema, quando tento gravar e existe algum erro, o próprio banco de dados retorna o que está errado. Ex: "Nome não informado" ou "Código do Produto duplicado", etc! Posso fazer algo parecido no SQL Server?
>
R: O funcionamento dos triggers é diferente no SQL Server do VFP, o SQL dispara o trigger
para o ultimo registro de um conjunto de dados enviados, emquanto o VFP dispara para cada registro.
Se vc usar ODBC e CA isto não muda.
Eu uso muito Stored Procedures e posso controlar tudo no SQL Server.
Sim vc pode controlar tudo fazendo verificações usando Codigo no SQL e retornar uma mensagem de erro.

>
>Conexão
>Onde eu posso gravar os dados do servidor do SQL, usuário, senha, etc? Internamente no EXE?
>
R: Crie um arquivo .ini e grave neste local os dados necessário para estabelecer uma conexão via SQLSTRINGCONNECT()

>
>Segurança
>Crio um usuário genérico para todos os usuários ou um usuário no SQL para cada usuário do sistema?
>Atualmente eu tenho uma tabela de usuários com as permissões de cada um: Pesquisar Cliente, Incluir Cliente, Alterar Cliente, Excluir Cliente, etc... E também algo do tipo: Desconto máximo permitido, etc.
>No SQL Server, vou manter esse mesmo esquema, certo?
>
R: Para controlar o que cada usuário faz, crie uma tabela no SQL como no VFP, e coloque em uma matriz no frontend p/ controlar as permissães daquele usuario.
Existe um nivel de segurança maior no SQL server, vc pode criar a segurança para cada uauário, ou um generico para todos, mas existe tambem a segurança a nivel de aplicação, significa que somente a aplicação pode acessar a base de dados, este caminho é mais facil.

>
>
>bom, é "só" isso... :-)

R: a curva de aprendizagem é acendente....e a explicação aqui é superficial....
para comparar, o help do SQL é 16x maior que do VFP e não trata de interface grafica como no VFP.

[ ]'s
Peter