Carregando relatórios em front-end desvinculado.

Olá amigos

Estou para lançar um artigo no meu site, abordando esta questão, de carregar os relatórios sem a presença das tabelas vinculadas.

Quem aqui costuma usar os front-end's desacoplados, poderia me informar como lidam com esta questão ?

Grato!

E aí Avelino, tranquilo? Eu uso muito esse artifício de carregar relatórios e formulários sem nenhuma tabela vinculada e sem nenhuma consulta no frontend. Vamos supor um relatório no qual eu carrego o cabeçalho no evento "Ao carregar" e o detalhe no evento "Ao abrir":

Código:

Private Sub Report_Load()

On Error GoTo TErro

Dim rs As DAO.Recordset, Reg As String

Set rs = DBEngine.Workspaces(0).OpenDatabase(CurrentProject.Path & "\DataBase.accdb", False, False, "MS Access;PWD=senha").OpenRecordset("SELECT * FROM tblProdutos WHERE Código=" & Forms!frmPrincipal!cboProduto.Column(0) & "")

Me.txtProduct = rs!Descrição
Me.txtASource = rs!ASource
Me.txtAPart = rs!APart
Me.txtUses = rs!Uses
Me.txtGDesc = rs!GeneralDescription
Me.txtSCond = rs!StorageConditions
Me.txtPT = rs!PT

rs.Close
Set rs = Nothing

DoCmd.Maximize

TErro:

    If Err.Number <> 0 Then
        DoCmd.OpenForm "frmTErro"
        Forms!frmTErro!txtENum = Err.Number
        Forms!frmTErro!txtEDes = Err.Description
        Forms!frmTErro!txtNObj = Me.Name
        Forms!frmTErro!txtTObj = Application.CurrentObjectType
    End If

End Sub

Código:

Private Sub Report_Open(Cancel As Integer)
    Me.RecordSource = "Select * from tblExportaçãoCoA in ''[;Database=" & CurrentProject.Path & "\DataBase.accdb;PWD=senha] WHERE NumPedido like '" & Forms!frmPrincipal!cboPedido & "' And NumProduto like '" & Forms!frmPrincipal!cboProduto & "'"
End Sub

Em um dos relatórios, alem de carregar o cabeçalho e o detalhe, ainda tem um campo do detalhe a ser preenchido com um dado de outra tabela. Nesse caso, utilizo uma função para selecionar o dado de cada linha do detalhe de acordo o item da linha correta na tabela:

Código:

Private Function Prod() As String

Dim rs As Recordset
Set rs = DBEngine.Workspaces(0).OpenDatabase(CurrentProject.Path & "\DataBase.accdb", False, False, "MS Access;PWD=senha").OpenRecordset("SELECT * FROM tblProdutos WHERE Código=" & Forms!frmPrincipal!cboProduto.Value & "")
Prod = rs!Descrição
rs.Close
Set rs = Nothing

End Function

Nesse campo, no detalhe do relatório, colocamos na origem: =Prod()

Mais ou menos isso que eu faço.

Olá Valdino

Obrigado por responder.

Vejo então que para relatórios mas complexos o uso da SQL no RecordSource é a melhor, se não a única opção.

Private Sub Report_Open(Cancel As Integer)
Me.RecordSource = "Select * from tblExportaçãoCoA in ''[;Database=" & CurrentProject.Path & "\DataBase.accdb;PWD=senha] WHERE NumPedido like '" & Forms!frmPrincipal!cboPedido & "' And NumProduto like '" & Forms!frmPrincipal!cboProduto & "'"
End Sub

Porem, da forma como se encontra, existe um potencial risco de pegarem a senha do back-end. Como vc protege seu front-end ?


Aguem mais tem técnica de carregamento, diferente das apresentadas pelo Valdino ?

Eu converto o frontend para accde. Até o momento tem atendido sem problemas.

Só ? Tá lascado!!! (risos)

Monte um projetinho bem simples. (back-end e front-end).
Coloca a senha no back-end.
Monte um relatório carregando a sql pelo recordsource
Gere o seu front-end em accde

me envie, que irei te devolver com a senha do seu back-end

No aguardo

Valdino, terie que dar uma saida, volto às 11:00 h para gente continuar com essa questão.

Outra pergunta: A cada relatório vc fica inserindo esta linha na SQL ?

...CurrentProject.Path & "\DataBase.accdb;PWD=senha ...

Se tiver 50 relatórios e desejar modificar a senha e o caminho válido do back-end ? Então como vc padroniza isso ?

No aguardo

Geralmente as pessoas que trabalham aonde instalamos os aplicativos são bastante leigas em informática. A maioria só sabe utilizar messenger e acessar a Internet e mesmo assim com várias restrições, rsrsrs. Imagina se conseguirão abrir o aplicativo em modo design, abrir um relatório, abrir um módulo mesmo sem código e acinzentado, pedir para exibir a Janela de verificação imediata e requisitar um ? Application.Reports..., rsrsrs. Claro que uma hora pode aparecer um sujeito mais entendido, mas até o momento estamos tranquilos, hehehe. Por isso ainda não tive problemas com isso.

Quanto ao caminho, o que eu passei foi um genérico. Eu costumo inserir uma função para alterar parâmetros quando necessário e então referencio essa função nos relatórios e formulários:

Código:

Set rs = DBEngine.Workspaces(0).OpenDatabase(DBPath(Caminho) & "\DataBase.accdb", False, False, "MS Access;PWD='" & DBPath(pWord) & "'").OpenRecordset("SELECT * FROM tblProdutos WHERE Código=" & Forms!frmPrincipal!cboProduto.Column(0) & "")

Tudo bem Valdino... Estou questionando o problema para uma situação mais genérica, em que vc tenha que expor seu projeto na internet ou mesmo para o caso aonde exista os "espertinhos". Como faria para estes casos?

Mostre-me como vc montaria sua função DBPath(pWord), para casos em que segurança é relevante.

Só o Valdino trabalha com o BD desvinculado ? Niguém mais ? Alguém usa ADO? Se usa, o ADO tem algum recurso para carregar o recordset no relatório ? Vamos lá gente, quero criar um artigo que seja abrangente neste aspecto!

Grato!

Boa tarde, não querendo estar ao nível dos mestres.
Gostaria de mostrar um exemplo:

Para o relatório criei uma tabela local com os campos:

Cmp_Cod
Cmp_Desc
cat_desc
cmp_estfinal
ngalpao
e_nome
fil_nome

todos em formato de texto.

A idéia era de popular a tabela local e abrir o relatório diretamente no banco de dados,
como no interior do Piauí a internet não é muito boa agilizou bastante a abertura do relatório.


Código usado no relatório:

Private Sub Report_Close()
DoCmd.SetWarnings False
CurrentDb.Execute "DELETE * FROM rpt_listalotes;"
DoCmd.SetWarnings True
End Sub

Private Sub Report_Open(Cancel As Integer)
DoCmd.SetWarnings False
CurrentDb.Execute "DELETE * FROM rpt_listalotes;"
DoCmd.SetWarnings True
Call Povoar
DoCmd.MoveSize 2000, 400
End Sub

Private Sub Povoar()

DoCmd.Hourglass True

Dim strCon As String
'esta é a string de conexao
'devera conter a informacao sobre o provedor e o
'caminho do banco de dados

Dim strProv As String
'guarda o nome do provedor
Dim strDtSource As String
'guarda a fonte de dados
Dim strDtBaseName As String
'nome do banco de dados

Dim user_id As String ' identificacao do usuario para o banco de dados
Dim password As String ' a senha (se tiver) para o banco de dados
Dim IP2 As String ' o endereco ip da maquina na qual esta o mySql

IP2 = DLookup("[Valor]", "_Parametros", "[ID]=8") 'Servidor Web
user_id = DLookup("[Valor]", "_Parametros", "[ID]=10") 'Usuário do banco de dados
password = DLookup("[Valor]", "_Parametros", "[ID]=11") 'Senha do banco de dados
strDtBaseName = DLookup("[Valor]", "_Parametros", "[ID]=12") 'Database

' string de conexao
strCon = "driver={MySQL ODBC 5.1 Driver};server=" & IP2 & ";uid=" & user_id & ";pwd=" & password & ";database=" & strDtBaseName

Set adoDtConn = New ADODB.Connection
'preparando o objeto connection

adoDtConn.CursorLocation = adUseClient
'usamos um cursor do lado do cliente pois os dados
'serao acessados na maquina do cliente e nao de um servidor

adoDtConn.Open strCon
'Abreo o objeto connection

Set Rs1 = New ADODB.Recordset
'Prepara o recordset

Rs1.CursorType = adOpenStatic
'Este é o unico tipo de cursor a ser usado
'com um cursor localizado no lado do cliente

Rs1.CursorLocation = adUseClient
'estamos usando o cursor no cliente

Rs1.LockType = adLockPessimistic
'Isto garente que o registros que esta sendo editado
'pode ser salvo

Rs1.Source = "SELECT db_Cmp.CMP_ID, db_Empresa.E_NOME, db_Empresa.E_CNPJ, " & _
"db_Filial.FIL_NOME, db_Filial.FIL_CNPJ, db_Cmp.CMP_COD, " & _
"db_Galpao.NGalpao, db_Cmp.CMP_DESC, db_Categoria.Cat_Desc, " & _
"db_Cmp.CMP_EST_INI, db_Cmp.CMP_E_NASC, db_Cmp.CMP_E_COMPRA, " & _
"db_Cmp.CMP_S_MORTE, db_Cmp.CMP_S_CONSUMO, db_Cmp.CMP_S_VENDA, " & _
"db_Cmp.CMP_EST_FINAL, db_Cmp.CMP_DT_CAD, db_Cmp.USUARIO, " & _
"db_Cmp.DTMOV, db_Cmp.EstGeral, db_Cmp.Cmp_Descont " & _
"FROM " & _
"db_Cmp INNER JOIN " & _
"db_Empresa ON db_Cmp.EMPRESA_ID = db_Empresa.E_ID INNER JOIN " & _
"db_Filial ON db_Cmp.FILIAL_ID = db_Filial.FIL_ID AND " & _
"db_Filial.EMPRESA_ID = db_Empresa.E_ID INNER JOIN " & _
"db_Galpao ON db_Cmp.Cmp_Galpao_Id = db_Galpao.Id INNER JOIN " & _
"db_Categoria ON db_Cmp.CMP_CAT_ID = db_Categoria.Cat_Id " & _
"WHERE " & _
" db_Cmp.Cmp_Descont = 'S' " & _
" and db_Cmp.CMP_DT_CAD >'" & Forms!frmRelListaLotesDesc!DataMov1.Value & _
"' and db_Cmp.CMP_DT_CAD <'" & Forms!frmRelListaLotesDesc!DataMov2.Value & _
"' ORDER BY db_Cmp.CMP_COD;"

'a fonte de dados usamos uma instrucal SQL

Rs1.ActiveConnection = adoDtConn
'O recordset precisa saber qual a conexao em uso

Rs1.Open
'abre o recordset com isto o evento MoveComplete sera disparado
Dim rs4 As DAO.Recordset

Set rs4 = CurrentDb.OpenRecordset("rpt_listalotes")

While (Not Rs1.EOF)

With rs4
.AddNew
![Cmp_Cod] = Rs1![Cmp_Cod]
![Cmp_Desc] = Rs1![Cmp_Desc]
![cat_desc] = Rs1![cat_desc]
![cmp_estfinal] = Rs1![Cmp_Est_Final]
![ngalpao] = Rs1![ngalpao]
![e_nome] = Rs1![e_nome]
![fil_nome] = Rs1![fil_nome]
.Update
Rs1.MoveNext
End With
Wend

'Me.nregistros.Caption = "Nº de registros: " & Rs1.RecordCount

Rs1.Close
adoDtConn.Close

me.Requery

DoCmd.Hourglass False





End Sub

Jungli, mas nesse caso, a senha continua exposta de forma que um usuário mais avançado um pouco possa chegar até ela, não? Bem, acredito que se colocar o relatório como subrelatório de um outro relatório, dificultará o acesso até a senha via "Verificação imediata", pois, com o aplicativo no formato accde, não será possível alterar o código vba. Então, podemos colocar algo em um evento do subrelatório de forma que ele não possa ser aberto a não ser como um controle dentro do relatório principal. Como o Recordsource só é exibido com o relatório aberto e considerando que estando ele como subrelatório dentro de outro relatório a VI não consegue enxergá-lo, acredito que ajuda. Tambem podemos definir no evento "Ao carregar" do relatório principal para que ele só possa ser aberto à partir de um botão de um formulário. Como isso tudo será definido por vba e com o aplicativo compilado em accde, acredito que ajudará no processo.

Olá Glicerio!

Muito obrigado pela sua participação.

Muito válido a sua opção, de usar tabelas locais, e dai então utilizar os relatórios.

Este método é bastante trabalhoso, e arranca o coro do programador (risos). Sistemas desacoplados cobram um preço alto no quesito tempo, não é verdade!?

Estava com a esperança que o ADO nos desse a possibilidade de carregar o recordset direto no relatórios.

É verdade Mestre Criquio.
Estou estudando a opção de encryptação de dados via vba para proteger as tabelas principalmente a de parâmetros que estou usando, não decidi ainda mas estou pensando em pelo menos 2 níveis de encryptação.
Assim as informações reais só estariam disponíveis em tempo de execução, o quê você acha? Mestre?

Melhorou Glicerio, mas por que guardar tais informações na tabela ?? Por que não dentro do próprio VBA ?

Valdino, que embrolho é esse de relatórios!? Parece o time atual do Flamengo. kkkkkkk Se eu uso o aplicativo normalmente e abro o relatório pelo botão, eu chego ao recordSource do sub relatório do mesmo jeito.

Cadê o seu código que chama pela senha ? Vamos lá, o objetivo é agente ficar mais ligado com essas coisas e montar algo cada vez melhor. E aqui é o lugar para isso!

No aguardo

isto nao dá ?

foi o criquio por curiosidada

http://www.utteraccess.com/forum/lofiversion/index.php/t1975932.html

Boa tarde Avelino,

Porque então não colocar a string de conexão em um módulo?

Olá Raquel! Obrigado pela sua participação.

Bom, o que endendi por lá, foi o que o Valdino apresentou aqui.

Opa, charles! Como vc faria? Mostre a sua função e como vc aplicaria.

Minha ideia a princípo não é dizer a vcs como eu faria, mas saber como vcs estão fazendo e dar minha opinião nos problemas que podem estar enfrentando.

Coletando tudo isso, pretendo então montar um artigo sobre o tema.

No aguardo

A encryptação seria para as tebelas no servidor, no front só seriam preenchidas para popular o report a desencryptação só ocorreria em tempo de execução via VBA por segurança.

Dá trabalho pra fazer? sim, mas acho que compensa.

O quê me diz mestre Avelino.

Certamente dá para se chegar até a senha, mas o que estou dizendo é que ficará mais difícil, pois será preciso saber qual relatório está dentro de qual para poder passar o caminho completo. E para esculachar com tudo de vez, ainda podemos apelar e jogar vários níveis de camadas, colocando o subrelatório real dentro de um relatório que ficará dentro de outro que ficará dentro de outro e... (calma, estou brincando, kkkkkk).

No caso da senha em uma função, a ideia é a seguinte: criamos um módulo e dentro dele colocamos uma função. Vamos supor algo assim:

Código:

Public Function Senha() As String
    Senha = "123"
End Function

Public Function DBPath() As String
    DBPath = DLookup("Caminho", "tblConfig", "Código=1")
End Function

A ideia aqui é passar o caminho e a senha para cada RecordSource ou Recordset:

Código:

Me.RecordSource = "Select * from tblExportaçãoCoA in ''[;Database=" & DBPath & "\DataBase.accdb;PWD=" & Senha & "] WHERE NumPedido like '" & Forms!frmPrincipal!cboPedido & "' And NumProduto like '" & Forms!frmPrincipal!cboProduto & "'"

No caso da senha, quando quisermos alterá-la, bastará alterar na função do nosso accdb. No caso do caminho, podemos até colocar um PathPicker para alterar por um formulário mesmo.

Grande Valdino!

Poizé! Vá na janeja imediata e digite:

? senha

E me diga o que vc irá encontrar.

Glicerio

No código que vc apresentou, essa linha abaixo é que está ruim:

password = DLookup("[Valor]", "_Parametros", "[ID]=11") 'Senha do banco de dados

Por que ela está capturando a senha de uma tabela local. Acho que vc deveria por esta senha no proprio VBA, desde que esteja protegido com a extensão ACCDE. A questão que estou argumentando com o Valdino é aonde se deve por a senha, dentro do VBA. Se estiver criptografada, melhor ainda!

Mas você não irá dar o nome de senha para a sua função né? Foi só um exemplo
O nome da função tem que ser algo um pouquinho mais difícil de ser dedutível. Algo como zbxa25htk854v53htv85
Apesar de que, de qualquer forma, ainda pode ser possível listar as funções do aplicativo e, nesse caso, quanto mais difícil ela for, mas chamará a atenção. Talvez melhor colocar um nome que não lembre senha e nem chame a atenção.

Podemos tambem colocar um algo mais na função. Talvez utilizando um artifício para mudar os caracteres. Nossa senha pode ser 123 mas depois de digitar, converte para xhq por exemplo. xhq seria a senha real do bd. Uma espécie de criptografia.

Mas, como falei, ainda não vi a necessidade de utilizar tal artifício. Por isso, estou apenas hipoteticando

Valdino,

Mas você não irá dar o nome de senha para a sua função né? Foi só um exemplo
O nome da função tem que ser algo um pouquinho mais difícil de ser dedutível. Algo como zbxa25htk854v53htv85
Apesar de que, de qualquer forma, ainda pode ser possível listar as funções do aplicativo e, nesse caso, quanto mais difícil ela for, mas chamará a atenção. Talvez melhor colocar um nome que não lembre senha e nem chame a atenção.

O nome da função não importa. A grende zebra é que ela tem que ser PUBLIC, para ser possível utilizar em vários locais. Ai é que mora todo o perigo!

Podemos tambem colocar um algo mais na função. Talvez utilizando um artifício para mudar os caracteres. Nossa senha pode ser 123 mas depois de digitar, converte para xhq por exemplo. xhq seria a senha real do bd. Uma espécie de criptografia.

Ahhh, estamos chegando lá!!! Porque oferecer a função proposta já viu que não é o correto.

Mas, como falei, ainda não vi a necessidade de utilizar tal artifício. Por isso, estou apenas hipoteticando

Mas vai chegar um momento que um dia vai precisar e muitos aqui precisam.

Alguem aqui faz diferente ????

Boa noite,

Nunca trabalhei com back/front.
No entanto, há tempos procurei fazer um ficheiro DLL para guardar algumas funções que queria não expôr. Virei e revirei e não consegui implementar seu funcionamento.
Lendo este tema, veio-me à ideia que a senha pudesse ser armazenada numa DLL e ser acedida por uma função.
É uma ideia, apesar de não saber se será possível.

Olá Alexandre

Neste caso eu não saberia lhe dizer se este método é totalmente seguro.

O Jeferson, da kartoffel, já montou DLLs uzando o Visula basic 6. Entre em contato com ele e veja se ele pode demostrar como fazer.

Grato!

Olá para todos!

Quem aqui acha que seu aplicativo está bem protegido, desabilitando a tecla SHIFT, combinado com a extensão ACCDE, levanta o braço que eu quero fazer uma contagem!!!

Quem aqui usa uma função PUBLIC simples, passando a senha do seu back-end ?

Quem aqui usa senha do back-end na consulta SQL, passando direto para o RecordSource ?

Meu conselho é vocês utilizarem o meu aplicativo OPEN (gratuito) até se sentirem mais aptos no quesito segurança.

http://www.usandoaccess.com.br/tutoriais/tuto8.asp?id=1#inicio

E quanto ao carregamento de relatórios, niguém mais tem algo diferente do que foi aqui apresentado ?

Grato!

Bom dia, Mestres e amigos....

Tive uma pequena ideia ontem a noite e resolvi fazer um banco bem simples só pra testar.
Gostaria que algum dos mestres de mostrasse a senha deste banco de dados.
detalhe: não pegar diretamente a senha da base de dados, pegar a senha que está no front,
repito não tenho nem a intensão de estar no nível dos metres, mas gosto de brincar um pouco,
gostaria também que me informassem o tempo gasto e a forma que usaram para descobrir
a maneira que estou usando a senha para abrir a base.

No relatório só uso uma caixa de texto e formato diretamente ao inserir os dados nela, Usei DAO.

Obrigado, espero continuar aprendendo muito com os senhores.


* A pasta teste deve estar na Unidade C:
Ou pode mudar o caminho da base de dados na tabela: db_Servidor

Bom dia Avelino,

Não faço distribuição de aplicativos, mas eu faria algo assim no Front ACCDE com senha:

Um Banco Mysql hospedado e habilitado para acesso externo.

Uma Função Pública para a conexão:

Código:



Option Compare Database
Global cnn As ADODB.Connection

Public Sub Conecta_BD()
Set cnn = New ADODB.Connection
cnn.ConnectionString = "DRIVER={MySQL ODBC 5.1 Driver};SERVER=EndereçodoServidor;DATABASE=NomeDoBanco;UID=Usuario;PWD=Senha;OPTION=3"

End Sub

Public Sub Desconecta_BD()
cnn.Close
End Sub


Codigo Fonte de Um Formulário com uma Combobox não acoplada e um botão:

Código:


Option Compare Database
Dim rst As ADODB.Recordset
Dim strsql As String

Private Sub Cmd_AbreRelatorio_Click()
DoCmd.OpenReport "Rpt_Clientes", acViewPreview
End Sub

Private Sub Form_Load()

Conecta_BD
cnn.Open

If cnn.State <> adStateClosed Then
'inicia o recordset
Set rst = New ADODB.Recordset
'Configura o cursor
rst.CursorLocation = adUseClient
strsql = "SELECT Id_Cliente, NomeCliente FROM Clientes "
strsql = strsql & "ORDER BY NomeCliente;"
'Realiza a consulta
rst.Open strsql, cnn, adOpenDynamic, adLockOptimistic
If rst.EOF = True Then
MsgBox "Não há registros no momento.", vbInformation, ""
Else
Me.CmbCliente.RowSource = ""
Do While Not rst.EOF
Me.CmbCliente.AddItem rst!Id_Cliente & ";" & rst!NomeCliente
rst.MoveNext
Loop
rst.Close
Desconecta_BD
End If
End If

End Sub


Codigo fonte do relatório:

Código:


Private Sub Report_Load()
Conecta_BD
cnn.Open

If cnn.State <> adStateClosed Then
'inicia o recordset
Set rst = New ADODB.Recordset
'Configura o cursor
rst.CursorLocation = adUseClient
strsql = "SELECT Id_Cliente, NomeCliente, email FROM Clientes "
strsql = strsql & "WHERE Id_Cliente = " & Forms!FrmBusca!CmbCliente.Column(0)
'Realiza a consulta
rst.Open strsql, cnn, adOpenDynamic, adLockOptimistic
With rst
Me.txtIdCliente = !Id_Cliente
Me.txtNomeCliente = !NomeCliente
Me.txtMail = !email
End With
rst.Close
Desconecta_BD
End If

End Sub


Como alguém teria acesso ao módulo de conexão em um Accde??? Engenharia reversa??

Não sei se ajuda, mas eu utilizo esta dica do Mestre JPaulo e funciona.

http://maximoaccess.forumeiros.com/t1097-passwords-senhas-em-txt-ou-dll

Opa, Glicerio!

legal vc ter parado para refletir sobre o assunto!

Baixei o aplicativo , porém ele apresenta um erro.

Abro o formulário
preencho os campos com meus dados
quando clico para abrir o relatório, da erro na programação.

Verifique!

No aguardo

Mestre Avelino, Qual erro está informando?

Olá Charles

Obrigado pela participação

Veja, neste seu código não vejo risco algum em sua senha ser capturada. Assim como não há risco algum em usar a conexao feita como o DAO.

public bd as dao.database
Public Sub abreConexao()
Set bd = OpenDatabase("c:\maestro\maestro_v3_be.accdb", False, False, ";pwd=a1234")
End Sub

Mas a questão principal aqui é que, devemos estar atentos no uso de funções públicas, que possam oferecer ao oponente algo indevido, como a senha neste caso abaixo:

public function fncSenha() as string
fncSenha = "minhasenha"
end function

Charles, me diga: Como vc monta relatórios mais complexos ? Porque esse apresentado foi mamão com açucar. Como fica para apresentar resultados com varias linhas de registro ?

Grato!

Glicério

Segue imagem:

Bom Avelino, era só um relatório de teste.

Bem lembrado mestre.

Quando lidamos com função e variável publica, devemos bloquear

as teclas especiais e retirar da ribbon o acesso ao VBA antes de criar o accde

Já que o asunto é OFF, me diga qualquer conta de email que vc usa, que te mostro como envio um

relatorio HTML automaticamente a qualquer hora do dia e onde voce estiver

Interessante não.

É um aplicativo que desenvolvi para resposta automatica por email, com base em uma pequena

matriz digitada no campo assunto do email. É muito mais seguro e funcional.

Mestre Avelino,
Abra a tabela db_Servidor, nela o senhor coloca o caminho da base de dados, deixei o padrão C:\teste\TesteBase.mdb

Já existem 3 registros na tabela.

Olá Mario

Obrigado por participar.

Por que a senha tem que estar fora do BD ? E vc tem uma enorme quantidade de linhas para recuperá-la. Imagine que vc tenha uma seria de locais que precise deste código para extrair a senha. Ou seja, é uma função cadidata a ser Pública e não Privada.

E veja a função fornecida:

Public Function Serial()
'By JPaulo ® Maximo Access
Serial = "c:\windows\system32\Serial.txt"
End Function

É exatamente o que estou chamando atenção de vcs aqui. Se eu executar esta função na janela imediata do VBA, terei o endereço do arquivo txt.

Glicerio, irei ver seu arquivo daqui a pouco e lhe darei meu parecer.

Grato!

Mais uma dica para utilizar uma senha passada em uma função pública pode ser utilizar uma tabela de conversão ou algo do tipo. Vamos supor que a senha do bd seja 123 mas na função pública colocamos abc e aonde colocamos a função nos formulários e relatórios faríamos a conversão de acordo a tabela de substituição. Isso ajudaria a dificultar as coisas para quem quisesse tentar invadir o sistema. Exemplo:

Código:

Private Sub Report_Open(Cancel As Integer)
    Dim DBPass As String
    DBPass = Replace(Replace(Replace(Senha, "a", "1"), "b", "2"), "c", "3")
    Me.RecordSource = "Select * from tblExportaçãoCoA in ''[;Database=" & CurrentProject.Path & "\DataBase.accdb;PWD=" & DBPass & "] WHERE NumPedido like '" & Forms!frmPrincipal!cboPedido & "' And NumProduto like '" & Forms!frmPrincipal!cboProduto & "'"
End Sub

É só uma amostra. Na prática melhoraríamos a forma de conversão.

Avelino,

Se a variável cnn for limpa ao encerrar a conexão, não tem como você conseguir

a string através da Janela Imediata. Tem jeito de conseguir???

Código:


Option Compare Database
Global cnn As ADODB.Connection

Public Sub Conecta_BD()
Set cnn = New ADODB.Connection
cnn.ConnectionString = "DRIVER={MySQL ODBC 5.1 Driver};SERVER=EndereçodoServidor;DATABASE=NomeDoBanco;UID=Usuario;PWD=Senha;OPTION=3"

End Sub

Public Sub Desconecta_BD()
cnn.Close
'Aqui eu inseri a linha para limpar a variavel
Set cnn = Nothing
End Sub


Sds,

boas noites aos grandes mestres e companhia.
começo por dizer que db access é muito vulneravel, é muito facil manipular, logo projectos em access sao muito vulneraveis.
1- não adianta escondermos passwords se a db não estiver escondida também, a informação está nas tabelas, e para ter acesso as tabelas chega ter um programa que procure pass e dois dedos, um para clicar em shift e outro em enter.
2- adianta sim esconder as pass se tivermos a db num servidor seguro, aí contamos com a segurança do servidor e neste caso usaria encriptação sha1 e guardada na db não testei em access mas provavelmente dá, ou em variavel em vba e limitar o acesso.

cumps
acao

Olá amigos! Eu uso meus relatórios desacoplados da mesma forma que o Valdino mostrou(sql pelo recordsource).
E uma das coisas que mais me preocupo é com a segurança dos dados dos clientes e por isso estou acompanhando este tópico e tive uma idéia.
Em anexo, tenho um pequeno aplicativo com um formulário e um relatório carregado da forma que descrevi acima (que é a forma em que percebemos a vulnerabilidade da descoberta da senha do back-end). Tentem descobrir a senha do back-end e me informem qual é.

Grato e no aguardo!

Obs.: FrontEnd e BackEnd na mesma pasta.

No aguardo.

Olá meus amigos!

Peço desculpas pela minha ausência de ontem a tarde.

Glicério,

Testei o seu projeto:

Não tem funções no modulo global para eu analisar, se sofre algum risco. Para esse seu teste, foi ponto positivo não usar funções globais. Porém, cometeu um erro grave com a variável global Sentrada

Depois que eu carreguei seu relatório, coloque na janela Imediata:

? sentrada
Gjr123456http7890@

Pois bem: entrei com a senha no seu back-end e vc tentou se defender com o formulário do tipo pop-up mas se esqueceu que um simples CTRL+G ou ALT+F11 chegamos no VBA. Alterei o seu botão de saida para fechar o formulário e entrei na sua base.

Sei que foi apenas um teste, mas fica alguns conselhos:

Nunca use o Back-end com extensão MDB. Tem um monte de programinha, gratuito inclusive, que descobre a senha.
Não confie somente na senha do VBA. Passe para o ACCDE. Também tem programas pela internet, que descobrem a senha. Porem procure sempre usa-la, pois é mais uma barreira para desanimar o oponente.

Olá Charles

Bom Avelino, era só um relatório de teste.

Vejo até agora por parte de vocês que os relatórios são muito comprometidos, quando não usado com o RecordSource. Claro, tem relatórios que basta popular alguns campos e ficam satisfatórios. De tudo que me foi apresentado até agora, o que mais me agradou foi o uso de tabelas, pois assim podemos usar todos os recursos nativos dos relatórios de forma plena.

Para o caso da SQL com senha, carregada direto no RecordSource, eu usaria sem medo, com o OPEN. Por que o OPEN força o uso da extensão ACCDR, que impede qualquer tentativa de se chegar a janela imediata. E força o uso da senha do Access, que é extremamente segura, impedindo o invasor de usar um BD externo.

Bem lembrado mestre.

Quando lidamos com função e variável publica, devemos bloquear

as teclas especiais e retirar da ribbon o acesso ao VBA antes de criar o accde

Se eu tiver acesso as Opções do Access, eu desbloqueio isso. Como vc defenderia as "Opções do Access" ?

Já que o asunto é OFF, me diga qualquer conta de email que vc usa, que te mostro como envio um

relatorio HTML automaticamente a qualquer hora do dia e onde voce estiver

Eu demostro um pouco desta tecnica no meu artigo Access x outlook.

Interessante não.

É um aplicativo que desenvolvi para resposta automatica por email, com base em uma pequena

matriz digitada no campo assunto do email. É muito mais seguro e funcional.

avelino(arroba)usandoaccess(ponto)com(ponto)br

Olá Valdino!!!!

Não adiantará nada se vc entregar a senha final ao RecordSource

A unica coisa que vc melhorou, e muito, foi a defesa da senha, passada pela função Public.

Charles,

como eu havia dito, não vi problema algum no seu código, relativo a segurança da sua senha.

A janela imediata não consegue manipular a variável cnn

Olá Acao!

Obrigado por participar!

ô pá, tu estais completamente enganado! Nós é que permitimos a vulnerabilidade!

1- não adianta escondermos passwords se a db não estiver escondida também, a informação está nas tabelas, e para ter acesso as tabelas chega ter um programa que procure pass e dois dedos, um para clicar em shift e outro em enter.

Vc deveria conhecer o OPEN e assitir a vídeo-aula que eu ofereço.

2- adianta sim esconder as pass se tivermos a db num servidor seguro, aí contamos com a segurança do servidor e neste caso usaria encriptação sha1 e guardada na db não testei em access mas provavelmente dá, ou em variavel em vba e limitar o acesso.

Poderia esplicar melhor? Esconder senha no servidor para que? Que senha seria essa ?

Grande Marcelo!!!

Gostei de você por aqui!

Seu exemplo está na versão 2010. Poucos aqui conseguirão abrir.

Infelizmente sua tática, de coibir as teclas no relatório, não serviu! Bastou eu abrir a janela imedianta, antes da abertura do relatório e minimizá-la. Abri o seu relatório e então usei a janela imediata para te pegar(risos)!

Sua senha: 9247

Mestre Avelino,
Obrigado mais uma vez pelas dicas,
farei modificações e retornarei mais tarde o projeto atualizado para novos testes.

Bom dia Avelino, bom é ter sua participação e seu desafio em nossa comunidade!! Isso é enriquecedor ainda mais!
É verdade Avelino, não me atentei para essa possibilidade já abrir a janela imediata, essa é a senha mesmo...
Vou tentar pensar em algo por aqui...