MIGRACAO DE BANCO DE DADOS
Vou responder a sua pergunta do PORQUE o ORACLE é o BICHO??
No SQL SERVER, muitas vezes VC fica "engessado" no padrão MICROSOFT de cirar cursores e DAtaTypes, no ORACLE, ele te dá uma facilidade ENORME pra este tipo de ciração.
Quando VC tÃÅ m um sistema GRANDE, ROBUSTO ao qual VC precisa estar criando diversos cursores num único processo, no SQL SERVER ele fica lento, e quando o SQL SERVER não se perde no meio destes cursores, ele te dá um resultado. Isso quando VC consegue rodar todos os processos sem erro.
No ORACLE, VC consegue prever os erros com mais facilidade, tratar o erro em CURSORES, e continuar o processo como se não tivesse ocorrido este erro. Já no SQL SERVER ele para o processo.
No ORACLE é PRATICAMENTE IMPOSSà ÂVEL vc criar um processo, e este processo travar a sua máquina (lógico, desde que VC tenha uma BOA Mà ÂQUINA pra isso). No SQL SERVER, SE VC fizer um LOOP INFINITO sem querer, e só se tocar 1 hora depois, a máquina já estará travando. No ORACLE, a performance da máquina CAIRà Â, mas não travará a sua Base de Dados.
Bom, os dois são FANTà ÂSTICOS, tanto o ORACLE como o SQL SERVER, só que são MUITO CAROS, e num sisteminha de locadora não vale a pena este investimento. Trabalhei durante muito tempo com o POSTRE SQL, ao qual me trouxe resultados muito BONS e SATISFATÓ“RIOS com o valor que havia pago pelo produto (cerca de R$ 800,00 a 2 anos atrás), e a vantagem ENORME: Ele é OPENSOUCE, e não preciso ter registro por usuário logado nele, só registro por máquina instalada
No SQL SERVER, muitas vezes VC fica "engessado" no padrão MICROSOFT de cirar cursores e DAtaTypes, no ORACLE, ele te dá uma facilidade ENORME pra este tipo de ciração.
Quando VC tÃÅ m um sistema GRANDE, ROBUSTO ao qual VC precisa estar criando diversos cursores num único processo, no SQL SERVER ele fica lento, e quando o SQL SERVER não se perde no meio destes cursores, ele te dá um resultado. Isso quando VC consegue rodar todos os processos sem erro.
No ORACLE, VC consegue prever os erros com mais facilidade, tratar o erro em CURSORES, e continuar o processo como se não tivesse ocorrido este erro. Já no SQL SERVER ele para o processo.
No ORACLE é PRATICAMENTE IMPOSSà ÂVEL vc criar um processo, e este processo travar a sua máquina (lógico, desde que VC tenha uma BOA Mà ÂQUINA pra isso). No SQL SERVER, SE VC fizer um LOOP INFINITO sem querer, e só se tocar 1 hora depois, a máquina já estará travando. No ORACLE, a performance da máquina CAIRà Â, mas não travará a sua Base de Dados.
Bom, os dois são FANTà ÂSTICOS, tanto o ORACLE como o SQL SERVER, só que são MUITO CAROS, e num sisteminha de locadora não vale a pena este investimento. Trabalhei durante muito tempo com o POSTRE SQL, ao qual me trouxe resultados muito BONS e SATISFATÓ“RIOS com o valor que havia pago pelo produto (cerca de R$ 800,00 a 2 anos atrás), e a vantagem ENORME: Ele é OPENSOUCE, e não preciso ter registro por usuário logado nele, só registro por máquina instalada
Gabriel... o MSDE é configurado por DOS, mas vc pode baixar um administrador gráfico para ele, como o MSDE Admin.
PESSOAL ESTOU TB COM ESSA DUVIDA. PRECISO URGENTE TROCAR MEU ACCESS, TODOS FALAM DO FIREBIRD, MAS ESTOU TENTANDO USALO MAIS ELE é MUITO LENTO. EX: FIZ UM TESTE COM O ACESS E O FIREBIRD, 100 MIL REGISTRO EU ABRI NO ACCESS COM O JET 4 EM 3 SEGUNDOS, Jà  COM O FIREBIRD ABRIU 24 SEGUNDOS, A DIFERENCA E ENORME, NAO Dà  PARA EU USAR O FIREBIRD, SE ALGUEM TIVER IDEIA POR FAVOR ME AJUDEM TB.
luisnet10@hotmail.com
luisnet10@hotmail.com
Desculpem se estiver falando bobeira, mas o MSDE é para no máximo 05 usuários simultà ¢neos, não é???
bem... ai não sei dizer...
Gente pra quem não conheçe a performace do MSDE vejam o arqigo:
http://www.eggheadcafe.com/articles/20021110.asp (Original em Inglês)
http://66.94.231.168/language/translatedPage2?lp=en_pt&text=http%3A%2F%2Fwww.eggheadcafe.com%2Farticles%2F20021110.asp&.intl=cd&frame=translatedPage&who=gsp (Versão em Português Traduzida)
http://www.eggheadcafe.com/articles/20021110.asp (Original em Inglês)
http://66.94.231.168/language/translatedPage2?lp=en_pt&text=http%3A%2F%2Fwww.eggheadcafe.com%2Farticles%2F20021110.asp&.intl=cd&frame=translatedPage&who=gsp (Versão em Português Traduzida)
AMIGOS, este assunto esta sendo discutido, mas acho q nenhuma conclusão logica foi dada. Infelismente eu ainda não posso fazer isso.. Peço para nos membros mais experientes q possam nos ajudar dando alguma definição. Qual utilizar, para quem defende o FIREBIRD como usa-lo se a diferenca em carregar um tabela qt ao access e tão grande. Tento não acher vcs de perguntas, mas estou totalmente perdido neste assunto, sempre trabalhei com o access.
Prezados colegas
Inconformado com o desempenho do Firebird em relação ao Access, resolvi mudar de Drive de conexão, estava usando o Ibole.dll
Instalei o Firebird ODBC (http://firebird.sourceforge.net/index.php?op=files&id=odbc) e o desempenho melhorou muito, ficando praticamente igual ao do access.
O tempo para se conectar via Ibole.dll estava em torno de 8 a 9 segundos (local), com o Firebird ODBC caiu para 3 a 4 segundos (a primeira vez).
E o preenchimento de um listview que era no mÃnimo 50% mais demorado, ficou praticamente igual ao do Access.
Abraços
Inconformado com o desempenho do Firebird em relação ao Access, resolvi mudar de Drive de conexão, estava usando o Ibole.dll
Instalei o Firebird ODBC (http://firebird.sourceforge.net/index.php?op=files&id=odbc) e o desempenho melhorou muito, ficando praticamente igual ao do access.
O tempo para se conectar via Ibole.dll estava em torno de 8 a 9 segundos (local), com o Firebird ODBC caiu para 3 a 4 segundos (a primeira vez).
E o preenchimento de um listview que era no mÃnimo 50% mais demorado, ficou praticamente igual ao do Access.
Abraços
VALEU PELA DICA RICARDO, VOU TENTAR
Só para completar, li um artigo no site do colega Macoratti, que talvez possa ajudar a melhorar ainda mais o desempenho no preenchimento de grids
Selecionando registro de um Recordset usando GetRows
Selecionando registro de um Recordset usando GetRows
Tópico encerrado , respostas não são mais permitidas