Tentando fazer um calendário eficiente no Microsoft Access
então o que eu gostaria de fazer, é encontrar uma maneira de tornar isto eficiente, enquanto ainda usando sub-formas, encontrar outro controle que funciona em local de sub-formas, ou para mudar as sub-formas para fora com listas, mas de alguma forma ainda ser capaz de formatar as cores das linhas. Eu entendo que isso é impossível com listboxes como é, mas eu sou um programador, e estou disposto a tentar subclassing listboxes para fazer isso se ele não vai perder muito do meu tempo. Infelizmente eu nunca fiz nenhuma subclassing vba, assim que eu precisaria ser apontado a alguns recursos bons para fazê-lo.
o código para definir a fonte de registo de cada sub-reforma diária é como
f("sub" & X & Y).Form.RecordSource = "SELECT * " & _
"FROM QRY_Calendar " & _
"WHERE CDate(StartDate) <= #" & curDate & "# " & _
"AND ((EndDate IS NULL OR CDate(EndDate) >= #" & curDate & "#)" & _
IIf(CDate(curDate) <= Date, " OR ((Date_In IS NULL OR CDate(Date_In) >= #" & curDate & "#) AND Date_Out IS NOT NULL)", "") & ") " & _
"ORDER BY IIF(Date_Out Is Not Null And (Date_In Is Null Or CDate2(Date_In)>=#" & curDate & "#) And CDate2(EndDate)<#" & curDate & "#,0,iif(CDate2(Date_Out)<=#" & curDate & "# And (Date_In Is Null Or CDate2(Date_In)>=#" & curDate & "#),1,2)), ID"
QRY_Calendar parece-se com isto:
SELECT B.ID, Person, Initials, ProjectNum & '-' & ProjectYear & '-' & Format(TaskNum,'000') AS Project, Sign_Out_Code, Value AS Type, StartDate, EndDate, Date_Out, Date_In
FROM (((TBL_Booking AS B INNER JOIN TBL_Person AS P ON B.PersonID = P.ID) INNER JOIN LKUP_List AS T ON B.EquipTypeID = T.ID) LEFT JOIN TBL_Usage AS U ON B.ID = U.BookingID) LEFT JOIN TBL_Equipment AS E ON U.Equipment_ID = E.ID;
StartDate e EndDate na tabela TBL_Booking são o início e o fim de uma reserva, e Date_Out e Date_In na tabela TBL_Usage são o início e o fim de uma sessão. Cada assinatura está ligada a uma reserva através do livro de chaves estrangeiro. Se a Date_In for nula, isso significa que o equipamento está atualmente assinado.
O LKUP_List é uma tabela de nomes mal conhecidos de antes de eu começar a trabalhar nisto há anos que eu nunca me dei ao trabalho de mudar. Contém uma lista (entre outras coisas) de tipos de equipamentos. Reservas são para tipos de equipamentos e não itens específicos, e quando um usuário assina fora de seu equipamento, um registro na TBL_Usage é criado que está ligado a uma peça específica de equipamento.
Se alguém tem ideias sobre a direcção que devo tomar com isto e Onde posso procurar orientação, seria muito apreciado.5 answers
Em primeiro lugar, a carga de 42 sub-formas uma forma de acesso é extremamente rápida, e de fato eu tenho feito isso por anos e anos e o tempo de carga de 42 sub-formas é de fato instantâneo.
Isto sugere que os leitores aqui podem ignorar alguns comentários que sugerem que um sistema de interpretação baseado em 'script' ou em texto, como o HTML, seria de alguma forma mais rápido a correr dentro de algum tipo de Sistema de renderização de navegador, em comparação com uma aplicação de ecrã de alto desempenho do windows que tem quase a capacidade direta de escrever diretamente para a placa de vídeo gráfico.
Lembre-se se tiver o conhecimento simples e básico de que as aplicações do Windows desktop podem escrever directamente nas placas de vídeo, então poucos tentariam comparar e sugerir que um sistema renderizado em HTML tem alguma esperança real de comparar em termos de velocidade se compararmos as duas arquitecturas diferentes aqui.
Então o verdadeiro problema aqui é o quão rápido o calendário pode ser feito para correr e will 42 sub os formulários são um problema?A resposta é simplesmente que 42 sub-formas não é um problema e são rápidos!
O seguinte calendário de acesso Meu torna - se próximo instantaneamente.
O meu calendário de acesso acima tem sido usado durante anos mesmo em ambientes de produção. Mesmo que os calendários tenham cada dia com mais dados que não podem caber na tela, é instanct em tempo de carga. Um bom número destes está em execução no qual o desktop (cliente) está batendo uma infra-estrutura de servidor SQL Através de conexões de INTERNET padrão para uma versão hospedada do servidor SQL rodando em um site web. E mesmo neste caso de largura de banda mais limitada, o tempo de carga e a resposta do calendário é quase instantânea. Por isso o desempenho é sem um problema, independentemente se eu usar um accDB (baseada em arquivo) back-end, usando o SQL server para o back-end, e ainda mais incrível e, como observou o formulário funciona bem com muitos dos meus clientes executando este Acesso calendário regular de conexões de internet em que o back-end do SQL servidor rodando em um site hospedado. E eu até tenho uma versão rodando com um SharePoint (lista) back end e novamente ele funciona sem problema e atraso perceptível.
O desenho acima tem 42 sub-formas, e como observado sem dados, as sub-formas carregam-se quase imediatamente. É importante que afirme isso e, portanto, eu tenho fornecido alguma evidência real e factual para depreciar os outros comentários feitos aqui por aqueles que claramente não entendem e entendem arquitetura básica de computador. As as pessoas sugeririam, assim, que o carregamento de 42 sub-formas está de alguma forma em questão em termos de desaceleração do software quando, na verdade, eu posso facilmente demonstrar que isso não é o caso. Como tal, o testemunho e testemunho de outros aqui pode ser mostrado sem mérito e, como tal, esta visão é baseada na falta de compreensão de como as operações básicas de computadores funcionam em nossa indústria. HTML não pode esperar para comparar com tal configuração aqui.
E falando em web baseado agora que o acesso permite a web publicando então eu posto o seguinte vídeo de um calendário construído no Access que corre em um navegador web. Este calendário baseado no navegador foi construído apenas usando o Access e sem quaisquer ferramentas de terceiros.Http://www.youtube.com/watch?v=AU4mH0jPntI
O resultado do vídeo acima mostra uma versão web suave manteiga e instantaneamente sensível desta aplicação de calendário.
Agora eu devo salientar que no exemplo acima baseado na web eu não uso 42 sub-formulários desde que em um navegador web cada formulário é um frame separado e causa uma re-renderização do formulário que é enviado a partir do servidor. Isto significa para o Access web baseado em um projeto baseado em 42 sub-formulários está fora de questão. Você vai sofrer um grande sucesso de desempenho em termos de renderização (mesmo se não há dados desde que o formulário XMAL é carregado a pedido para economizar tempo, mas neste caso esta configuração dói).
No entanto, como o vídeo mostra a solução para web baseado (e também funcionaria para cliente) foi para preencher uma tabela em que você liga as caixas de texto a essa tabela. Assim, ter um display de registro é como observado e mostrado no vídeo acima mostra que tal resultado significa uma resposta quase instantânea e como observado mesmo em um navegador web.
Sublinho a aplicação baseada na WEB, na medida em que o vídeo foi construído apenas com acesso e sem Outras ferramentas.
Voltando agora aos problemas de desempenho e a uma aplicação baseada no cliente. O problema, naturalmente, como sabemos agora, é que carregar 42 formulários não é um problema.É claro que a questão é executar 42 consultas SQL separadas com todos os tipos de expressões para puxar dados para essas sub-formas é onde o estrangulamento e desempenho lento vai ocorrer. Como tal, este problema de desempenho não vai mudar se usarmos 42 caixas de texto, ou mesmo 42 listboxes.
Então a questão é a de tentar executar 42 consultas SQL separadas. Tenha em mente que cada consulta SQL leva tempo para analisar, tempo para verificar a sintaxe, e então os planos de consulta etc. são construídas. De facto a um grande número de ações têm que ocorrer antes que os dados comecem a fluir para essa consulta. Eu de fato acho que uma consulta pode ser o custo de cerca de 10.000 linhas de fluxo de dados em termos de largura de banda.
Com base na informação acima, a razão pela qual, com o meu design, essas 42 sub-formas podem carregar e executar instantaneamente é devido ao facto de eu executar apenas uma consulta para devolver os dados para todo o mês. Em outras palavras, eu executo uma consulta com a data de início e data de fim para exibicao. Eu então executei o código VBA para processar esses dados do reocrdset resultante em sub forma 1 a 42. Então o código VBA stuffs the resulting record set data into the 42 sub forms. Então este é o conceito e sugestão chave aqui para garantir computação de alto desempenho e não ter uma desaceleração.
Em resumo e conclusão:
O gargalo de desempenho não é o de usar 42 sub-formas, mas o de ter 42 conjuntos de registos e 42 consultas, e código potencialmente adicional e expressões que têm de ser avaliadas 42 vezes. Eliminar as 42 consultas e as 42 vezes e ter que executar de novo tais declarações SQL e este gargalo vai praticamente evaporar.
Atrevo-me a dizer que usar 42 caixas de lista, ou mesmo apenas 42 caixas de texto e continuar a executar 42 tais declarações SQL não irá produzir quaisquer melhorias de desempenho que valham a pena.
Uma pergunta relacionada com calendários foi feita não há muito tempo: criando uma 'matriz de calendário' no acesso
Dito isto, provavelmente nunca conseguirás um bom desempenho com 43 sub-formas ligadas a consultas não triviais.Pequena melhoria possível
Não está a dizer se os seus dados estão num servidor de infra-estrutura, caso em que cada sub-estrutura tem de obter dados através da rede.Se for esse o caso, você pode estar melhor fazendo uma consulta ao servidor para recolhe todos os dados e guarda-os na parte da frente. Você teria então apenas que fazer simples filtragem em uma tabela local, que deve ser mais rápido, embora os 42 subforms provavelmente vão ser um grande gargalo para o desempenho.
Uma simples consulta {[[0]} pode dar-lhe início, desde que tenha criado uma tabela local chamada myCacheTable com base nos dados devolvidos da sua consulta normal.
Controlos leves
A primeira coisa que devias tentar era usar o venerávellistbox.É bastante leve e há muitas maneiras de configurá-los.
Se você combinar isso com dados de cache do servidor como eu mencionei acima, você poderia obter um melhor desempenho.
Controlos na Web
Como HelloW mencionado, pode ser uma boa ideia simplesmente usar caixas de texto configuradas para TextFormat = RichText e fornecê-las com HTML simples (não suporta muito) para formatar os dados dentro:
Full-on web Página
Talvez um pouco mais complexo de configurar, mas difícil de bater em termos de UI, poderia ser usar uma biblioteca de Javascript existente como FullCalendar, ou injectar o seu próprio html directamente no documento do navegador (você poderia usar o simples <table> para formatar o calendário).
Aqui está um exemplo do que um exemplo de calendário online Parece dentro de um WebBrowser controlo num formulário de Acesso:
Concordo com a ideia de que isto funcionará melhor em HTML.
Substituir cada sub-forma por um campo de texto formatado para texto rico. Em seguida, na carga do formulário (ou algum outro evento ) obter um recordset para o mês e loop através dele adicionando o texto a cada caixa de texto. O subconjunto HTML disponível é geralmente suficiente para obter a maioria da formatação que você precisa.
Considerações
-
Isto vai levar algum tempo até à vba. O mais provável é que não te importes com isto, já que ... já cheguei até aqui.
- Só há uma consulta para que a velocidade possa ser mais aceitável {[[9]}
- as suas marcas de HTML serão
<br>e as marcas de cores - Você não será capaz de mudar a cor de fundo apenas a cor do texto (eu posso estar errado aqui)
Outra solução seria fazer muitos controles de caixa de texto, cada um representando o registro no dia do calendário.
Corre uma consulta-rápido!
No ciclo VBA através de cada controlo de caixa de texto e atribuir - lhe a posição horizontal e vertical, o conteúdo (valor), o formato, a visibilidade (não é necessário mostrar os sem dados).
Para Baixo, tem de decidir com antecedência quantos controlos de caixa de texto necessita e pode não ser suficiente para todos os registos entregues por consulta.
Para superar este problema, você pode decidir arbitrariamente que você tem 100 controles apenas mostrando primeiramente registros mais importantes do seu recordset (ex. Em atraso), e fazendo uma nota que "nem todos os registros mostrados". Se o usuário quiser ver todos os registros, ele clica em determinada data, e mais detalhada subforme Abre, que mostra todos os registros para esta data.
Nunca tentei no calendário, mas tenho um formulário com o gráfico Gantt, que mostra as barras temporais. Cada barra de tempo é um controle de caixa de texto. Eu tenho 120 controles e funciona instantaneamente.Outra solução é usar o Tcal, que acabei de actualizar para a versão 1.4.2. O que é o Tcal? Tcal é um calendário de plataforma Cliente-Servidor com uma interface gráfica completa. Usando TcalServer e TCP / IP, Tcal registra eventos, prazos e horas de trabalho para a sua empresa personalizada FileMaker Pro, Microsoft Access ou arquivos de banco de dados MySQL. Você pode alocar recursos e nomes de tarefas para seus eventos, Ver outros calendários de recursos, aceitar ou recusar convite. O Tcal trabalha no Mac OSX e no Window (7 ou XP) e é gratuito, para max 2 usuários conectados. Você pode encontrar Tcal aqui: http://www.tcal.it/eng/index.html