emotta

uma forma de proteger um arquivo ao subir para o S3 é subir o arquivo para o bucket acrescentando UUID nele, exemplo: https://nomedomeubucket.s3.us-east-2.amazonaws.com/files/notafiscal/20210825/notafiscal_d57213af-3ae6-41f7-b91e-254444008256.pdf nesse caso o arquivo subiu para o bucket: nomedomeubucket na pasta /files/notafiscal/20210825 com o nome: notafiscal_d57213af-3ae6-41f7-b91e-254444008256.pdf

no caso do S3 você configura o BUCKET (que é como se fosse o HD onde vc grava os arquivos) se ele libera o acesso pra quem tiver o link do arquivo ou se é protegido. Nos vídeos que passei acima fala disso, dê uma olhada.

aqui tem como configurar subindo qualquer arquivo para o S3 pelo prompt do windows

Vejam esse video que tem uma explicação de todo processo, mas o exemplo que o cara usou é em DELPHI. Mas da pra pegar exatamente a idéia

Usando assim acredito que não afeta a performance mas isso pode gerar efeitos colaterais desagradáveis, por exemplo, se vc tiver o SQL SERVER EXPRESS que tem o limite de 10gb pode acontecer de preencher esse limite rapidamente. Também gera um problema ao fazer backup, você terá o backup grande sendo que 90% dele é devido aos arquivos em campo blob. Outro detalhe importante é que se o arquivo não for texto você deve guardar ele como HEXA ou em BASE64 e com isso você terá um arquivo de 1mb sendo gravado no SQL em quase 2mb (quase o dobro). Enfim, você estará usando o SQL como um repositório de arquivos. O SQL não foi feito pra isso. O correto e mais seguro é usar como repositório de arquivo algo que foi feito pra ser repositório de arquivo. Eu citei no post anterior minha experiência desagradável fazendo desta maneira onde um backup do meu banco de dados gerava vários gigas de tamanho e depois que transferi os arquivos para o S3 o backup do banco de dados caiu para pouco mais de 100mb (considerando o backup compactado) Se você faz desta maneira pra guardar arquivos sugiro a rever isso, o S3 é infinitamente melhor. Estude sobre isso e tire suas próprias conclusões, só estou expondo aqui a experiência que tive neste assunto.

desaconselho fortemente a gravar isso no banco de dados. Falo isso por experiencia desastrosa que já tive. O banco de dados fica pesado demais, ocupa um espaço gigantesco após um tempo com essas informações. Minha experiencia foi no sistema administrativo local, que fizemos internamente só pra gerenciar nosso financeiro. Criamos uma tabela e um campo blob pra guardar PDF, DOCs, etc. Após um pouco o banco tinha 9gb sendo que 8gb era só desses arquivos. Então fiz uma limpa, tirei tudo isso do banco de dados e expotei para o S3 e na tabela que antes tinha um blob hoje em dia tem apenas um link apontando para o arquivo no S3 da amazon. Resumindo: Nosso banco de dados caiu pra menos de 1gb e os arquivos todos estão na nuvem. Eduardo, estude sobre o S3 e comece a usar, é barato e fica disponivel o arquivo pra quem tiver o link. O cuidado que você deve ter é de subir o arquivo e no nome do arquivo colocar algo pra tornar o link impossivel de descobrir, exemplo: contrato-32820237702792019742798342579528725984534.pdf

Que legal essas funções, eu não as conhecia. Obrigado por compartilhar

Pega ai essa bem simplificada e eficaz. A funcao u_Teste é um exemplo de uso ArrayToString transforma o array em string (na verdade um json) StringToArray lê o json salvo em arraytostring e devolve o array pronto Function u_Teste() Local aDados := {} Local nI For nI := 1 to 10 aadd(aDados, nI) Next cSave_Array := ArrayToString(aDados) aNew_Array := StringToArray(cSave_Array) MsgStop(Sr_ShowVector(aNew_Array)) Return Static Function ArrayToString(aDados) Local hDados := Hash() hDados["ARRAY"] := aDados Return hb_jsonEncode(hDados,.t.) Static Function StringToArray(cDados) Local hDados := Hash() Local aDados := {} try hb_jsondecode(cDados, @hDados) aDados := hDados["ARRAY"] catch end Return aDados

Ano passado foi levantado a questão do vscode aqui, vale muito a pena, ainda mais se usado em conjunto com o GIT para versionamento dos fontes Dê uma olhada no link que tem tudo que vc precisa saber pra usar vscode com xharbour http://fivewin.com.br/index.php?/topic/28389-vs-code/&tab=comments#comment-287654

save to não é do fivewin e sim do (x)harbour salvar e restaurar variáveis gera uma brecha de segurança nos sistemas mas se quiser usar tenta assim: save to nomefields all like v_* extended e use tb o extended para o restore caso não funcione tente compilar o seu fonte passando -kx

GIT é o software de controle de versionamento mais usado atualmente, é simples de usar e grátis. Ele faz o que o antigo Source Safe fazia ou então como o SVN. GITHUB é uma forma de colocar seu repositório de fontes (GIT) na internet, ou seja, é uma espécie de googledrive. Você pode criar repositórios públicos (que qualquer um pode baixar) ou privados (somente pessoas autorizadas). Para repositórios públicos é grátis e sem limite. Para repositórios privados tem um limite de 2gb que é um tamanho muito bom pois em repositórios não deve ir executáveis e dlls, somente devem ir os arquivos fontes e outros pequenos. Aqui tem um vídeo com curso de git e github para iniciantes no windows.

Wellington já que está disponibilizando os fontes sugiro a colocar no github, lá ficará mais acessivel e quando você fizer implementações que queira disponibilizar a todos novamente não precisa ficar subindo nada. Alem do que, caso ainda não use o git para versionamento de fontes, pode ser uma boa oportunidade de praticar o uso do git.

Você tem dois modelos, um vc contrata uma VM (virtual machine) que é um computador em um datacenter. Nessa máquina vc instala o SQL e administra vc mesmo o servidor e os backups. Outra opção é vc contratar um SQL gerenciado pelo próprio servidor do datacenter. Neste caso vc tem acesso ao database e não a máquina em si, mas ganha em troca não ter dor de cabeça com backup e atualização de versão do SQL pois o datacenter faz isso pra vc. Eu uso a opção 2 no Azure que é AZURE SQL DATABASE. O AWS tb tem esse serviço que deve ser o RDS citado pelo sygecon. Outros provedores não conheço. No meu caso as vms e o database uso do Azure e o servidor de arquivos (cdn) uso o S3 da aws.

após o oHTTP := CreateObject( "MSXML2.ServerXMLHTTP.6.0" ) coloque: oHttp:setOption(2) := 13056

Segue o fonte que uso sem problemas já a um bom tempo. Hoje é usada diariamente pra subir arquivos para o S3 da AWS milhares de vezes ao dia e sem problemas. // ****************** COLOCAR A CALLENDPOINT no FUNGENA.PRG // cMode = POST/PUT/DELETE/GET // cJSon = JSon de chamada da API // aHeader = {{"Content-Type","application/json" }} (ESTE É O DEFAULT CASO NAO INFORMADO) Function CallEndPoint(cMode,cLink,cJSon,aHeader,nStatus_code) Local cResp := "" Local nI Static oHTTP nStatus_code := 0 If aHeader == NIL aHeader := {{"Content-Type","application/json" }} EndIf // oHTTP := CreateObject( "MSXML2.XMLHTTP" ) If oHTTP == nil oHTTP := CreateObject( "MSXML2.ServerXMLHTTP.6.0" ) oHTTP:SetTimeouts(600000, 600000, 600000, 600000) EndIf oHTTP:Open( cMode, cLink, .F. ) For nI := 1 to Len(aHeader) oHTTP:SetRequestHeader( aHeader[nI,1],aHeader[nI,2] ) Next Try oHTTP:Send(cJson) while oHTTP:readyState # 4 oHTTP:waitForResponse(1000) enddo nStatus_code := oHTTP:status cResp := oHTTP:responseText Catch End oHTTP:Abort() // Release oHttp // oHTTP := NIL HB_GCALL(.t.) Return cResp

xDev é top, usei por muitos anos... Realmente tinha algumas situações que travava mas dava conta do recado. Ano passado mudamos aqui na empresa para o VSCODE (devido ao xDev não ter mais manutenção), aconselho você a dar uma estudada nele, muito bom também.

ah entendi... como eu nunca utilizou editor de recursos então passo reto nessa... vlwwww kapiaba

acredito que se falar do que se trata vai gerar maior interesse

eu uso muito pra fazer o que chamo de "ponto de entrada" (quem conhece microsiga sabe o que estou dizendo) Imagina que um cliente seu deseja que toda vez que se inclui um novo fornecedor ele receba um email. Em vez de você criar um parametro e deixar isso no seu fonte padrão (que vc distribui para todos clientes) eu deixo isso fora do executavel. Na pasta onde você instala o sistema (onde fica o executavel) crie uma subpasta chamada HRB. Dentro dessa pasta você coloca os HRBs daquele cliente. Então no seu codigo fonte padrão, após a inclusão do fornecedor você coloca assim: If ExistHRB("enviar_email_inclusao_fornecedor) ExecHrb("enviar_email_inclusao_fornecedor") EndIf Na funcao ExistHRB vc faz um IF FILE(name_hrb) retornando .T. se o arquivo existir ou .F. se não existir na funcao ExecHrb vc faz o hrbload, hrbdo, hrbunload Faço dessa forma em meus sistemas desktop, você pode criar o seu formato a partir dessa idéia ou das outras que foram dadas. Abraços

Segue um exemplo de uso. Uso HRB a quase 20 anos, desde que ainda era instável o seu funcionamento para strings. Function u_Teste() Local oScript oScript := __hrbLoad( "myprog.hrb" ) __hrbDo( oScript, uPar01, uPar02, uPar03) // caso o HRB receba mais parametros basta criar uPar04, uPar05, ..., uPar99 __hrbUnload( oScript ) Return

Eu começaria da seguinte forma: Geraria um QRCODE pelo internet banking a partir da minha conta. Depois, com um leitor de qrcode, iria ler o qrcode e ver o texto gerado e comparar com o manual. Depois disso, a partir do exemplo simples que postei que gera um qrcode, eu geraria o mesmo texto do qrcode gerado inicialmente e tentaria fazer a transferencia (a partir de outra conta). Enfim, eu começaria desta forma. Talvez lhe ajude. Como essa questão do PIX não é tão prioritária pra mim no momento tive que deixar pra depois devido outras questões. abraços

Não peguei pra ver isso, estou em cima da LGPD. Mas com o meu exemplo pra gerar o QRCODE e com o layout que vc postou deve ser tranquilo de fazer, basta ter paciencia pra ler o manual e gerar o codigo. Pela rapida lida que dei vc precisa apenas montar os caracteres de acordo com o exigido no manual, nada mais é do que uma lista de numeros e letras.

Ladnilson até entendo que algumas empresas ainda tenham sistemas redondos em clipper que não querem trocar, mas isso é um cenário atípico. Você dificilmente consegue vender hoje em dia um sistema console para um cliente, essa é a verdade. Sobre sistemas desktop ainda se consegue mas cada vez está ficando mais difícil ante a concorrência com sistemas web e na nuvem, sem exigir que se instale nada. O cliente ganha apenas um login e senha inicial e já sai usando. Os pontos que citei acima são fatos e nem é opinião. Então mediante esse cenário, cada vez mais na web e em aplicativos de celulares, se recusar a aprender essa tecnologia é ir contra o que um programador é de fato. Programador é curioso, fuçador, busca tudo que é de novo e sai mexendo. O que é bom se absorve e o que é ruim fica como experiência. Tenho certeza que foi isso que levou você a conhecer dBase II em disquete de 8 polegadas em PC-500. Eu mexi também com dBase III, foi o primeiro local que fiz rodar um programa, comecei profissionalmente em 93 já com Clipper, fuçando conheci Harbour e ainda em 99 compilei meu primeiro hello world. Conheci fivewin em 2000, fuçando também, na época tinha a news da fivetech, dos caras daqui deste fórum o gilmer e o vagner participavam la tb, deve ter outros mas que não lembro. Em 2002, quando já tinha empresa e um sistema em clipper/fivewin eu arrisquei converter o sistema para xharbour/fivewin, quando xharbour era até instavel, mas me arrisquei pois era 16bits já estava complicado, GPFs fechavam o sistema do nada, então a migração foi inevitável. Já em 2006 integrei SQLRDD e isso possibilitou o uso de banco de dados SQL no sistema, focamos no SQL SERVER. Eu disse tudo isso pra ver que a evolução é inevitável e se quiser novos clientes e estar preparando para o que vem tem que atualizar o conhecimento e saber programar em web é obrigatório pra qualquer programador hoje em dia, quer você queira ou não. Linguagens como Ruby ou Python são grátis pois são open source. Para o frontend react.js tb é gratuito e tudo tem vasto material na WEB pra se consumir, sem qualquer custo. Então o que disse foi apenas uma dica, nunca disse pra abandonar (x)harbour/fivewin ou sair trocando o sistema dos clientes, eu não fiz isso e não recomendo ninguem fazer. Mas se quiser novos clientes ou bons empregos, saber programar em web vai abrir mais oportunidades a quem correr atras. Em tempo: tenho ainda muitos clientes contentes com a versão desktop que não irão migrar e mesmo na versão web, que tem o frontend em react.js e o backend em ruby on rails, tem tb coisa em xharbour, é só usar a criatividade que da pra integrar tudo. Só o que não pode é se recusar a aprender algo novo, fazer isso é dar um tiro no pé. Abraços, boa sexta-feira

Ladnilson, vc levantou uma questão importante agora... "Somos poucos agora pois muitos migraram..." vc tem toda razão, se alguém aqui programa somente em (x)harbour (fivewin ou não) e desconhece qualquer coisa de programação em web (front ou back end) deveria correr atrás disso, mesmo o mod_harbour vai exibir conhecimentos totalmente novos, não é pegar a aplicação desktop, compilar e ter a aplicação web. São coisas totalmente novas. (x)harbour/fivewin é uma excelente tecnologia, mas pra desktop, graças a eles não morremos com clipper no fim dos anos 90. Na web ainda vejo pouca coisa no mod_harbour e até agora não vi nenhum aplicativo em produção construído com ele. Se não tivesse migrado as aplicações da minha empresa pra web estaria perdendo muitas vendas de novos sistemas. Então sugiro a quem ainda não está nessa área correr atrás. Tem as linguagens python e Ruby que são fáceis e tem vasto material na web, para o front end recomendo o react.js. Mas são apenas dicas. abraços

sugiro colocar a cidade da empresa então, vai filtrar os interessados