Clipper On Line • Ver Tópico - ADO / SQLMIX / ADOXB

ADO / SQLMIX / ADOXB

Discussão sobre SQL

Moderador: Moderadores

 

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 16 Mar 2015 11:43

Provavelmente isso das half-open connections seja uma delas.
Até o Windows 2000 o limite era 67 milhões de conexões incompletas, e a partir do Windows XP isso foi alterado pra apenas 10 conexões, um valor quase 7 milhões de vezes menor.

E se der erro, é considerado como possível programa perigoso... rs

http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=4226&EvtSrc=Tcpip&LCID=1033

Há vários programas na internet pra mexer nesse limite, mas não sei se é uma boa idéia.
Acho que o ideal é mesmo manter uma única conexão.

Só pra reforçar: Não há limite de conexões abertas no Windows, O limite é pra conexões meio-abertas, que não são consideradas abertas e nem fechadas. Estão ainda iniciando a conexão, ou então o cache do Windows que não fecha instantâneo e elas ainda estão fechando.

Provavelmente essa é uma diferença do Linux, e era uma diferença no próprio Windows até o Windows 2000.

No geral, os problemas do Windows são causados pela Microsoft.
Assim que surge algo novo, ela inventa alguma configuração que atrapalha o antigo.
Precisava reduzir de 67 milhões pra apenas 10?
Se o Windows e as máquinas evoluiram, parece estranho limitar tanto assim.

Apesar de parecer fora do assunto do MySql/Servidor, isso afeta ficar abrindo/fechando conexões muitas vezes e em intervalos pequenos.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 18 Mar 2015 13:01

Tive uma dificuldade outro dia pra liberar acesso pra um usuário no MySql.
Não sei se é exclusividade do Linux, ou se é da versão nova do MySql.

grant all privileges on database.* to 'usuario'@'%' identified by 'senha'
grant all privileges on database.* to usuario identified by 'senha'


Isso foi uma coisa que precisei usar. Na primeira sintaxe, é definido o IP que poderá ter acesso, e não só o nome do usuário.
No caso do IP, % indica todos.

Esse é um recurso do MySql, não sei se em todos os bancos de dados cliente/servidor tem isso.

Podemos definir o que cada usuário pode fazer, e qual IP ele pode usar.
No comando acima, foi liberado tudo para o usuário.
Geralmente, o acesso é limitado a uma base de dados.

É assim que os provedores fazem.
Tem inúmeros bancos de dados no servidor, e liberam somente um pra sua senha.
Também podem definir que comandos podem ser executados, por exemplo pra não liberar pra outro usuário, ou só consulta (SELECT).

Então, supondo que sua estrutura de servidor seja boa, pode colocar todos os clientes no mesmo servidor.
E se quiser que o próprio usuário cuide da base que é dele, só liberar uma senha pra ele, com acesso somente ao banco de dados dele.

Nada de pastas, diretórios, configurações diferentes por empresa.
É o usuário e senha que definem quem pode fazer o que, e aonde.
E tudo via comandos SQL.

E se o sistema controlar várias empresas/filiais, cada um num banco de dados, sem problema.
Se o usuário/senha puder mexer em tudo, sempre vai ser uma única conexão com o banco de dados.

Uma única conexãozinha pra tudo....
Limite de arquivos abertos na máquina, limite de arquivos abertos na rede, limite de compartilhamento, problemas de diretório sem acesso, compartilhar pasta do servidor, mapear pasta em rede, proteção pra usuários não mexerem nos DBFs, etc. etc.
Nada disso existe mais.

E se o servidor for seu, e a internet for boa, em todas as máquinas do cliente vai só o EXE e o "driver" (odbc) do MySql.

Quem está acostumado com DBF acha isso tudo doido, acha que pode dar problema e se complicar.
E quem está acostumado com isso, acha DBF coisa de doido, porque tem que se preocupar com tudo descrito acima.

Pra não dizer que correu tudo bem com meu uso...
Não sei porque, está dando erro de vez em quando, na hora de fechar a conexão.
Mas fechar conexão é apenas fechar, é encerrar o programa.
Não é igual DBF que precisa salvar o que está em cache, porque não existe cache.
Então pode-se dizer que não tem nenhum problema. Se for o caso é só esconder o erro usando begin sequence/end sequence.
Provavelmente é daquelas coisas da conexão ter sido destruída pelo Windows por falta de uso.

Por enquanto uso 3 conexões: uma pro servidor do cliente, uma pro meu servidor de NFE, e outra pro meu servidor da internet.
Cada um tem uma finalidade específica.
O meu, uso há anos, não quis alterar isso por enquanto, é pra documentos eletrônicos.
O da internet, esse movi há pouco tempo, uma parte que ficava no meu servidor, porque em determinado cliente meu ip era bloqueado. Simpifiquei fazendo isso - controle de atualização de versão, bases de dados fixas, help online.
E o do cliente, é pra onde comecei a mover os DBFs do cliente.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 26 Mar 2015 09:47

Faltou dizer:

oConexao := win-OleCreateObject( "ADODB.Connection" )


Ao usar isso no aplicativo, se consultar no gerenciador de tarefas, vai ver que seu aplicativo passa a usar uns 6 processos de uma vez.
Provavelmente o Windows/ADO usam processos adicionais pra agilizar tudo.
Não sei se isso obrigaria a compilar com multithread (-mt). Como uso isso normalmente, não sei dizer se faz diferença não usar.

Estou expandindo o uso a mais clientes.
Atualmente ainda tenho a opção DBF ou MySql, mas quero eliminar os IFs dos fontes.
Pensei na opção do Access pra eliminar arquivos DBFs fixos mais rápido sem depender de servidor.
Não sei se usando Access somente leitura os arquivos ainda poderiam corromper em rede.

Vantagem que vejo em usar Access:
- um único arquivo físico com vários arquivos dentro.
- Comandos SQL, o mesmo fonte pra MySql vale pra Access, então menos IFs do que DBF

Desvantagem:
- Assim como DBF, sujeito a problemas de rede/energia/etc., mas corromper um arquivo físico com vários arquivos internos vai ser muito pior do que se fossem vários DBFs

Minha intenção final é somente MySql.
Acontece que o processo todo deve demorar um ano ou mais.
Estou alterando o aplicativo em uso. É passar um arquivo pra MySql e ir instalando o aplicativo nos clientes.
Pra evitar duplicação de fonte, ou muitos IFs, é onde entraria o Access.
Serve pra máquinas sozinhas, ou pros arquivos fixos, como tabela IBPT, CFOP, CST ICMS, CST IPI, CST PIS, CST Cofins, enquadramento PIS, enquadramento Cofins, cidades, UFs, etc.
Pra estes arquivos, ao invés de uma versão do cadastro em DBF e outra em MySql, uma única versão usando ADO que serve pra MySql e Access.
Por enquanto é somente uma idéia, caso seja problema mexer em instalação de clientes.

Tem a opção do meu servidor que facilitaria tudo, mas fica dependente da internet do cliente e da minha, são mais fatores intermediários de risco. No Brasil ainda não dá pra confiar totalmente em internet.
E obrigar internet reserva e outras coisas mais, só pra uso parcial, acho exagerado, e obriga investimento do lado do cliente e do meu lado.
Ainda é cedo pra isso.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 27 Mar 2015 13:00

Atualizando minha posição atual:

Em 4 empresas, já instalei e estou usando o MySql.
Apesar de ter migrado um único arquivo, o mais usado no aplicativo (o tempo todo), quero eliminar de vez a rotina alternativa de DBF, e isso só vai ser possível se instalar MySql em todo mundo.

Aproveitando....
A instalação do MySql no Windows está fácil.
Estou usando o MySql Community, última versão.
Na instalação é selecionar a opção de intermediário (nem dedicado e nem de desenvolvimento), cadastrar a senha de root, e cadastrar o usuário adicional com acesso externo à máquina.

Instalo também o HeidiSql, pra já testar a conexão, criar o banco de dados, e o arquivo inicial.

Por último, apenas acrescento no aplicativo o endereço do servidor e pronto.

O uso ainda representa pouco para o aplicativo, mas representa muito por ser toda configuração funcionando e pronta pra expansão.
Vai ser todo mundo de uma vez, migrando um arquivo por vez.
É mais demorado desse jeito, e impede de aproveitar mais recursos do MySql pra manter compatibilidade.

Mas se considerar que não é teste, já está rodando pra valer, mesmo que apenas parcial, tá valendo a pena.

De quebra, como se trata do registro de tudo que acontece no sistema, dá pra registrar muito mais coisas agora, porque não tem mais o limite dos DBFs.

Ah sim... gostei tanto disso que até esqueci que poderia cobrar. Realmente está sendo sem custo nenhum para os clientes.
O máximo que vou ganhar vai ser reclamação se der problema, mas tudo bem, vou em frente.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor fladimir » 27 Mar 2015 21:54

José parabéns, obrigado por compartilhar...

[]´s
Sun Tzu há mais de três mil anos cita nas epígrafes de seu livro “A Arte da Guerra“:

“Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças”.
“Se não é vantajoso, nunca envie suas tropas; se não lhe rende ganhos, nunca utilize seus homens; se não é uma situação perigosa, nunca lute uma batalha precipitada”
.


DESKTOP CONSOLE Harbour | MinGW | DBF | CDX | FastReport | MySQL
DESKTOP VISUAL... Harbour | MinGW | Xailer | MariaDB Nativo | FastReport
MOBILE Android/IOS e WEB - Windev Mobile 22
Avatar de usuário

fladimir
Colaborador

Colaborador
 
Mensagens: 2357
Data de registro: 15 Nov 2006 19:21
Curtiu: 25 vezes
Mens.Curtidas: 135 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 31 Mar 2015 14:46

Mais uma empresa hoje com MySql.
Pra facilitar a instalação, criei uma pequena checagem no banco de dados.

SHOW TABLES


Esse comando mostra as tabelas existentes no banco de dados.
Se não retornar nenhuma, significa que preciso criar o arquivo obrigatório.

E coloquei o nome do servidor no arquivo de configuração estilo xml:
<mysql>nome do servidor</mysql>

Assim que configuro o servidor, com usuário/senha padrão do aplicativo, coloco o nome dele nesse CFG e o aplicativo faz o resto.
Passa a ser usado o MySql ao invés do DBF.
O único adicional é chamar a opção "salvar no mysql", para salvar o conteúdo anterior.

Se conseguir instalar em todos os clientes, não vou precisar deixar alternativa pra DBF.

Nota: Continua sendo um único arquivo em MySql. É que os próximos possuem cadastro, e quero evitar fazer alternativa em DBF de tudo.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 02 Abr 2015 20:40

Nenhuma mensagem de erro hoje.
Mover STATIC variable para o fonte do módulo de fechar o ADO, aonde dava erro, parece ter feito diferença.
Pode ter sido coincidência, vamos ver se continua assim.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor rochinha » 06 Abr 2015 02:46

Amiguinhos,

JoséQuintas,
Só uma dica:

Um database no MySQL é basicamente uma pasta. Voce já tentou na instalação do seu sistema apenas criar a pasta do database via comando DOS? Desta forma voce não precisa entrar no aplicativo de manutenção para fazer "manualmente".
OPS! LINK QUEBRADO? Veja ESTE TOPICO antes e caso não encontre ENVIE seu email com link do tópico para fivolution@hotmail.com. Agradecido.

@braços : ? )

A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
Avatar de usuário

rochinha
Membro Master

Membro Master
 
Mensagens: 4209
Data de registro: 18 Ago 2003 20:43
Cidade/Estado: São Paulo - Brasil
Curtiu: 499 vezes
Mens.Curtidas: 182 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 06 Abr 2015 03:25

Mesmo que copie pastas, de qualquer forma tem que instalar o servidor.
Acaba sendo interessante fazer a instalação normal, e criar o banco de dados até mesmo pra testar.
Estou usando a última versão do MySql, talvez nas antigas fosse mais simples.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 24 Abr 2015 11:36

Refiz a parte de atualização de versão, onde verifico estruturas, atualizo conteúdos e outras coisas mais.
Até que ficou interessante.
Exemplo de DBF:
STATIC FUNCTION BA_GRUPCreateDbf()
   LOCAL mStruOk

   IF AppcnMySqlLocal() != NIL .AND. .NOT. File( "BA_GRUP.DBF" )
      RETURN NIL
   ENDIF
   SayScroll( "Verificando BA_GRUP.DBF" )
   mStruOk := { ;
      { "BGGRUPO",  "C", 10 }, ;
      { "BGRESUMO", "C", 10 }, ;
      { "BGMOSTRA", "C", 1 }, ;
      { "BGINFINC", "C", 80 }, ;
      { "BGINFALT", "C", 80 } }
   IF .NOT. ValidaStru( "ba_grup", mStruOk )
      MsgStop( "ba_grup não disponível!" )
      QUIT
   ENDIF
   RETURN NIL


Essa é a rotina que verifica a estrutura de BA_GRUP.DBF.
Passou a verificar somente se não for MySql ou se o DBF não existir.
Mesmo que seja MySql, pode ser que esse arquivo ainda não esteja no MySql, por isso a checagem.

Exemplo de MySql:
   IF AppcnMySqlLocal() == NIL
      RETURN NIL
   ENDIF
   ...
   cnMySql:ExecuteCmd( JPBARRACreateMySql() )
   IF File( "JPBARRA.DBF" )
      SayScroll( "Salvando JPBARRA no MySql" )
      CopyDbfToMySql( "JPBARRA", .T. )
      fErase( "jpbarra.dbf" )
   ENDIF


Se não existir MySql, já não faz nada.
Se existir o MySql e o DBF, significa que ainda não foi salvo no MySql, então salva e apaga.

A partir daí, o DBF deixou de existir, e não vai mais ser verificada estrutura na rotina de DBF (rotina anterior).

No programa de pedidos, por exemplo:
   IF AppcnMySqlLocal() == NIL
      IF .NOT. AbreArquivos( { "jpreguso", "jpbarra", "jpvvdem", "jpvvfin" } )
         RETURN
      ENDIF
   ENDIF
   IF .NOT. AbreArquivos( { "jpcadas", "jpcidade", "jpclista", "jpcomiss", "jpconfi", "jpdecret", "jpdolar", "jpedicfg", "jpempre", ;
      "jpestoq", "jpfinan", "jpforpag", "jpimpos", "jpitem", "jpitped", "jplfisc", "jpnota", "jpnumero", "jppedi", "jppreco", "jppromix", ;
      "jpsenha", "jptabel", "jptransa", "jpuf", "jpveicul", "jpvended", "jpibpt", "jppretab" } )
      RETURN
   ENDIF


Se não for MySql, abre jpreguso, jpbarra, jpvvdem e jpvvfin, porque não existirão mais estes arquivos em DBF.
E em MySql, não precisa abrir arquivo nenhum, então só restam os DBFs mesmo, que ainda não existem no MySql.

Na manutenção do log:

      IF MsgYesNo( "Confirma a exclusão?" )
         IF AppcnMySqlLocal() == NIL
            RecDelete()
         ELSE
            cnMySql:cSql := "DELETE FROM JPREGUSO WHERE RUARQUIVO=" + StringSql( temp->ruArquivo ) + " AND " + ;
               "RUCODIGO=" + StringSql( mruCodigo ) + " AND RUID=" + NumberSql( temp->RUID )
            cnMySql:ExecuteCmd()
            RecDelete()
         ENDIF
         KEYBOARD Chr( K_CTRL_PGUP )
      ENDIF


Este é um caso diferenciado. Como tem o arquivo temporário em DBF para o tbrowse quando MySql, além de apagar da base de dados, preciso apagar também do arquivo temporário.

Manter compatibilidade DBF e MySql acaba precisando trabalho/código extra.
Como vou deixar o sistema contábil pro final, tudo relacionado a ele vai ter que funcionar tabém em DBF até lá.
E também muita coisa do dia a dia.

Outro exemplo:
O arquivo de pedidos em DBF está sendo usado em diversos módulos, incluindo diversos relatórios.
Digamos que a mudança desse arquivo pra MySql pode demorar meses até ter tudo pronto.
Opções:
- Ficar meses alterando pra depois trocar no cliente pra MySql e ver o que dá
- Duplicar o arquivo de pedidos em DBF e MySql, e alterar um módulo por vez, sempre em uso no cliente.

A segunda opção é mais interessante.
Mas foi aí que pensei: porque não fazer isso com tudo de uma vez, e já aproveitar os recursos do MySql...

É por isso que estou demorando nesta etapa inicial, porque estou definindo o melhor jeito pra isso.
Alguns arquivos já estão diretamente no MySql, para os demais precisa pensar bem, pra não ter que voltar atrás.

De qualquer forma, a primeira coisa tinha que ser essa da mudança de estruturas e atualizações, pra funcionar tanto em DBF quanto em MySql.
Agora se precisar criar um campo novo em um arquivo, tanto faz se está em DBF ou MySql, o aplicativo ficou preparado pra isso.

O arquivo de código de barras, por exemplo, só era usado em um único cliente, então passar para MySql já eliminou esse DBF dos demais (só existe no MySql agora).

Com certeza quando chegar ao arquivo de pedidos, as mudanças terão que ser bem mais complexas.
Mas uma coisa de cada vez.
Estou indo devagar mas em frente.
Eliminar alguns DBFs aonde tem muitos terminais até dá uma pequena melhora no geral.
E ver o aplicativo usando MySql o tempo todo, sem problema algum, foi o impulso que faltava.

Quem estiver na dúvida pode fazer igual eu fiz: movi o arquivo de LOG para o MySql. É usado o tempo todo, é grande, e de certa forma o sistema não depende diretamente das informações dele pra funcionar. E dá pra deixar versão DBF/MySql simultâneo se for o caso. Acaba sendo um teste pesado, por ser usado o tempo todo.
Lógico, depende mais dos fontes do que qualquer coisa. Se seu fonte é bagunçado, vai ser bagunçado pra converter.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 24 Abr 2015 11:42

Faltou um exemplo de criar no MySql:

cnMySql:ExecuteCmd( JPREGUSOCreateMySql() )
...

FUNCTION JPREGUSOCreateMySql()
   RETURN ;
   "CREATE TABLE IF NOT EXISTS JPREGUSO ( " + ;
   "RUID INT(9) NOT NULL AUTO_INCREMENT, " + ;
   "RUARQUIVO CHAR(9) NOT NULL DEFAULT '', " + ;
   "RUCODIGO CHAR(9) NOT NULL DEFAULT '', " + ;
   "RUTEXTO CHAR(100) NOT NULL DEFAULT '', " + ;
   "RUINFINC CHAR(80) NOT NULL DEFAULT '', " + ;
   "PRIMARY KEY ( RUID ), " + ;
   "INDEX ARQUIVOCODIGO ( RUARQUIVO, RUCODIGO, RUID ) ) " + ;
   "COLLATE=latin1_swedish_ci ENGINE=InnoDB"


Não achei forma melhor de definir esse comando, num #include por exemplo, então deixei em função.
Esse é o comando que cria, caso não exista, e já cria a base e os índices de uma vez.
Acho que não precisaria o NOT NULL, já que possui um valor default, mas nem me preocupei com isso agora.
É do jeito que mostrou no HeidiSQL.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor rochinha » 26 Abr 2015 00:11

Amiguinhos,

José M Quintas,
Alguns postagens atrás voce falou sobre as vantagens de usar Access.

Uma coisa que sei é que o Access permite vincular .DBFs, ou seja, voce manipula estes arquivos como se fosse tabelas do Access. O impecilho é que os vinculos são engessados. Se voce vincular arquivos na pasta C:\SISTEMA mas mudá-los de lugar o .MDB não reconhecerá.

Ai me veio uma tarefa que até hoje não tive tempo de testar:

Como um .MDB tem controles naturais de acesso via online, ou seja, em sites é mais natural o seu uso tanto quanto MySQL e SQL Server, se um .MDB com DBFs vinculados também poderia ser manipulado remotamente.

Enfim nunca testei, mesmo porque tô na correria.
OPS! LINK QUEBRADO? Veja ESTE TOPICO antes e caso não encontre ENVIE seu email com link do tópico para fivolution@hotmail.com. Agradecido.

@braços : ? )

A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
Avatar de usuário

rochinha
Membro Master

Membro Master
 
Mensagens: 4209
Data de registro: 18 Ago 2003 20:43
Cidade/Estado: São Paulo - Brasil
Curtiu: 499 vezes
Mens.Curtidas: 182 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 26 Abr 2015 02:48

O problema é que o banco Access corre os mesmos riscos do DBF.
Como é tudo junto, o estrago pode ser grande.

O Access é usado em site, mas acaba trabalhando localmente aonde o site é hospedado, por isso o uso é tranquilo.
Em rede, corre o risco que mencionei.

Um caso que já falaram pra mim foi o seguinte:
Os usuários trabalharem normalmente o dia inteiro, e só vai acusar o arquivo corrompido no dia seguinte.
A mesma pessoa que comentou isso, usou o Access em rede por muito tempo (o arquivo MDB).
O programa Access, só no caso de alguma manutenção.

Esse uso vinculado, tentei usar uma vez mas não se deu muito bem.
Se for pra usar comando SQL, pode ser mais interessante usar DBF mesmo, e ADS Local, no modo compatível com CDX.

    cString = "Provider=Advantage.OLEDB.1;" & _
    "Mode=Share Deny None;" & _
    "Show Deleted Records in DBF Tables with Advantage=False;" & _
    "Data Source=" & Sistema.PathDefault & ";Advantage Server Type=ADS_Local_Server;" & _
    "TableType=ADS_CDX;Security Mode=ADS_IGNORERIGHTS;" & _
    "Lock Mode=Compatible;" & _
    "Use NULL values in DBF Tables with Advantage=True;" & _
    "Exclusive=No;Deleted=No;"


Nota:
ADS - Advantage Database Server
Pode ser usado com servidor ADS
Pode ser usado em rede, sem servidor ADS, que é chamado ADS Local
Neste último caso, é estilo DBF, aonde cada terminal atualiza os DBFs, mas sem servidor ADS instalado.

E complementando:
A string de conexão pra DBF contem o caminho dos DBFs.
Ao vincular com Access, o caminho acaba ficando fixo, por causa da string.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 29 Abr 2015 09:08

To chegando na parte de cadastros.
Mexi em dois.

Tenho lá meu formulário de cadastro genérico, onde tem o método pra mover ao primeiro registro

METHOD MoveFirst()
   GOTO TOP
   RETURN NIL


E no formulário de um determinado arquivo, que recebe o anterior por herança, não precisa nada.

Para um cadastro em MySql, acabei fazendo um método específico, onde mover ao primeiro registro significa mover ao menor código.

METHOD MoveFirst() CLASS JPDECRETClass
   LOCAL cnJPDECRET := ADOClass():New()
   cnJPDECRET:cn := AppcnMySqlLocal()
   IF AppcnMySqlLocal() == NIL
      ::Super:MoveFirst()
      ::axKeyValue[ 1 ] := jpdecret->DENUMLAN
   ELSE
      cnJPDECRET:cSql := "SELECT DENUMLAN FROM JPDECRET ORDER BY DENUMLAN LIMIT 1"
      cnJPDECRET:Execute()
      IF .NOT. cnJPDECRET:Eof()
         ::axKeyValue[ 1 ] := cnJPDECRET:StringSql( "DENUMLAN" )
      ENDIF
      cnJPDECRET:Rs:Close()
   ENDIF
   RETURN NIL


Fiz o primeiro, o segundo, mas depois consegui generalizar no formulário matriz.
Agora no formulário matriz, o método ficou assim:

METHOD MoveFirst() CLASS frmCadastroClass
   IF ::cnMySql == NIL
      GOTO TOP
   ELSE
      ::cnMySql:cSql := "SELECT " + ::cMySqlField + " FROM " + ::cMySqlTable + " ORDER BY " + ::cMySqlField + " LIMIT 1"
      ::cn:Execute()
      IF .NOT. ::cn:Eof()
         ::axKeyValue[ 1 ] := ::cn:StringSql( ::cMySqlField )
      ENDIF
      ::cn:rs:Close()
   ENDIF
   RETURN NIL


E no formulário de arquivo específico, só preciso colocar o nome de campo (::cMySqlField), o nome da tabela/arquivo (::cMySqlTable).
Com isso, deixei de precisar método diferente pra MySql.
Isso vai resolver a maioria, incluindo movimentação de financeiro, pedido, estoque, fiscal, e a maioria dos cadastros.

Só pra mostrar que:
No começo precisa muito código, pois estamos saindo do nosso "padrão confortável" e de nossa biblioteca pronta.
Com o tempo, vendo como funciona, podemos ir criando nossa biblioteca direcionada ao novo padrão.

No meu padrão atual todos os códigos são string. Quando isso mudar, vou ter que mudar esse método novamente.
Mas tudo bem, uma coisa de cada vez.

Obs.
No caso do último registro, só acrescentar DESC no SELECT, pra pegar em ordem decrescente, portanto, o maior código que será o último.
Isso já resolve ::MoveFirst() e ::MoveLast(), antigos GOTO TOP e GOTO BOTTOM.
Tenho exceções, mas verei quando chegar lá.

Isso mostra que o negócio é fazer.
O tempo mostra como facilitar as coisas.
E fazer sem ter pressa/prazo, e por etapas, torna as coisas mais tranquilas, porque dá tempo de ficar escolhendo o melhor jeito.

Sei que vou ter outras necessidades.
Tenho várias rotinas onde é usado o registro atual, como recálculo do pedido, ou recálculo dos ítens do pedido.
No SQL não existe registro atual, será necessário ter uma chave única de referência.
No caso dos pedidos, o número do pedido.
No caso dos ítens de pedido já vai precisar algo mais. Poderia ser pedido + produto, mas em pedidos de armazém existe o mesmo produto mais de uma vez, com preços diferentes, então será necessário trabalhar com uma chave única neste caso.
Verei quando chegar lá.
De qualquer forma, em todos os arquivos/tabelas no MySql já acrescentei uma chave extra, que seguindo o tradicional, chama-se ID.
No cadastro de clientes por exemplo, além de CDCODIGO, tem CDID que é um campo incremental, numerado automaticamente pelo MySql.
Aliás... já fiz uso disso no primeiro arquivo que converti, do log do sistema, pois precisava dessa identificação única.

Como já falei antes, ainda mantendo compatibilidade com o que existe em DBF.
Senão, poderia já usar esse campo ID pra criar relacionamentos fixos na base de dados.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

ADO / SQLMIX / ADOXB

Mensagempor JoséQuintas » 29 Abr 2015 09:59

Pode ser que venha uma dúvida aí:
Esse código todo, não seria mais rápido um GOTO TOP em DBF?
Talvez sim, talvez não.

Vamos pensar:

Abrir arquivo com 7 índices, e fazer o GOTO TOP ou GOTO BOTTOM
Em DBF o Harbour vai abrir 8 arquivos, posicionar um registro nos 8 arquivos, e depois o GOTOTOP/GOTO BOTTOM a mesma coisa.
Tudo isso passando pela rede, talvez 8 solicitações ao servidor, ou 16 considerando a abertura inicial.
E isso inclui trafegar o registro completo do DBF, todos os campos do registro.
Em SQL vai a solicitação ao servidor, e o servidor retorna um número (considerando o que eu fiz).

Se for um arquivo com estrutura grande, para um simples GOTO TOP já reduziu drasticamente o tráfego pela rede.

Dá trabalho mudar de DBF pra MySql, é mais código pra um simples GOTO TOP, mas é muito interessante.

Aproveito pra lembrar outra questão:
Existem bibliotecas pra trabalhar com MySql no estilo do DBF, isso facilita pra aproveitar todo código existente.
É bom conhecer como funcionam as coisas, porque se imaginar o processo acima, dependendo de como usar a biblioteca pode ter resultados diferentes no que se refere a velocidade.

A rotina no post anterior também funcionaria com SELECT *, mas ao invés de trazer apenas o código, traria o registro completo.
Mas se só interessa o código, melhor definir pra trazer só o código porque economiza rede.
José M. C. Quintas
Harbour 3.4, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, hbnetio, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"
Avatar de usuário

JoséQuintas
Colaborador

Colaborador
 
Mensagens: 11583
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 12 vezes
Mens.Curtidas: 740 vezes

Anterior Próximo



Retornar para SQL

Quem está online

Usuários vendo este fórum: Nenhum usuário registrado online e 1 visitante


Ola Amigo, espero que meu site e forum tem lhe beneficiado, com exemplos e dicas de programacao.
Entao divulgue o link da Doacao abaixo para seus amigos e redes sociais ou faça uma doacao para o site forum...
MUITO OBRIGADO PELA SUA DOACAO!
Faça uma doação para o forum
v
Olá visitante, seja bem-vindo ao Fórum Clipper On Line!
Efetue o seu login ou faça o seu Registro