Datastore ou armazem de dados é o objeto de interface oferecido por ORDA para fazer referência a um banco de dados e acessar a seu modelo e datos. Em 4D v17, só o banco de datos local, devolvido pelo comando ds, está disponível como armazem de dados.

Nota: os métodos e propriedades relacionados com Datastore são detalhados no capítulo ORDA - DataStore do manual de Linguagem.

Um armazem de dados está feito de um modelo e dados:

• O modelo contém e descreve todas as classes de dados que compõe o armazem de dados. é independente do banco de dados subjacente em si.
• Os datos se referem à informação que vai ser usada e  armazenar neste modelo. Por exemplo, os nomes, os endereços e as datas de nasciiento dos empregados são dados com os que pode trabalhar em um armazem de dados.

Quando se maneja através de código,o armazem de dados é um objeto cujas propriedades são todas as classes de dados definidas. Uma datastore faz referência apenas a um único banco de dados local ou remoto.

Podem acessar simultaneamente a uma datastore exposta em uma aplicação 4D Server através de diferentes clientes:

• as aplicações remotas 4D que utilizam ORDA para acessar ao datastore principal com ajuda do comando ds. Lembre que a aplicação remota 4D ainda pode acessar ao banco de dados em modo clássico. Estes acessos são entregados pelo servidor de aplicações 4D.
• Outras aplicações 4D (4D remoto, 4D Server) que abrem uma sessão na datastore remoto via o comando Open datastore. Estes acessos são entregados pelo servidor HTTP REST.
• Petições 4D for iOS para atualizar as aplicações iOS. Estes acessos são entregados pelo servidor HTTP.

O comando ds devolve uma referência ao armazém de dados predeterminado da aplicação. Quando chamar a este comando, 4D referencia automaticamente a cada tabela e campo do banco de dados 4D como atributos do objeto devolvido:

• as tabelas estão mapeadas a classes de dados
• os campos são atribuidos aos atributos de armazenamento
• os registros são assignadas às entidades
• as relações são assignadas a atributos de relação: os nomes de relação, definidos no editor de Estrutura, são usados como nomes de atributos de relação.
  

As regras abaixo se aplicam durante a conversão:

• os nomes de tabelas, campos e relações são assignados a nomes de propriedades de objetos. Se quiser utilizar a "notação de pontos" em ORDA, tenha certeza de que esses nomes cumpram com as regras gerais de denominação de objetos, como se explica na seção identificador notação objeto.
  Nota: As propriedades de relação "Manual" ou "Automatic" não têm efeito em ORDA.
• Um armazém de dados apenas referencia  tabelas com uma única chave principal (consulte Definir ou eliminar uma chave primária). As tabelas abaixo não estão referenciadas:
  • Tabelas sem chave primária
  • Tabelas com chaves primárias compostas.
• Os atributos de tipo BLOB não são gerenciados no armazém de dados. Os atributos de tipo BLOB são devolvidos como nulos nas entidades e não podem ser assignadas.

Qualquer modificação aplicada ao nível da estrutura de banco de dados invalida a camada de modelo ORDA atual. Essas modificações incluem:

• adicionar ou remover uma tabela, campo ou uma relação
• renomear uma tabela, um campo ou uma relação
• mudar uma propriedade chave de um campo (tipo, único, índice, autoincrementar, compatibilidade valor null)

Quando a camada de modelo atual ORDA for invalidada, ela é recarregada automaticamente e atualizada em chamadas subsequentes da datastore local ds em 4D e 4D Server. Note que refereências existentes para objetos ORDA tais como entidades ou seleção de entidades vão continuar a usar o modelo do qual foram criadas até que sejam regeneradas.

Entretanto, a capa de modelo ORDA atualizada não está automaticamente disponível nos contextos abaixos:

• uma aplicação remota 4D conectada a 4D Server -- a aplicação remota deve reconectar ao servidor. 
• uma datastore remota  (aberta usando Open datastore, ver abaixo) --uma nova sessão deve ser aberta. 

Quando trabalhar com uma datastore remota referenciada pelas chamadas ao comando Open datastore, a conexão entre os processos que efetuam a petição e a datastore remota são manejadas através de sessões.

Quando uma aplicação 4D (ou seja, um processo) abrir um datastore externo utilizando o comando Open datastore, se cria uma sesão no datastore remoto para manejar a conexão. Esta sessão se identifica utilizando uma ID de sessão interna que esteja associada a localID na aplicação 4D. Esta sessão administra automaticamente o acesso a dados, seleções de entidades ou entidades.

 localID é local à máquina que se conecta a datastore remota, o que significa que:

• Se outros processos da mesma aplicação necessitarem acessar a mesma datastore remota, podem utilizar a mesma localID e porttanto, compartir a mesma sessão.
• Se outro proceso da mesma aplicação abrir a mesma datastore remota mas com outra localID, criará uma nova sessão na datastore remoto.
• Se outra máquina se conectar a mesma datastore remota com a mesma localID, criará otura sessão com outro cookie.

Estes principios são ilustrados nos gráficos abaixo:

Os processos que administram as sessões de acesso a datastore são mostrados na janela de administração de 4D Server:

• nome: "REST Handler: <nome de processo>" 
• tipo: tipo HTTP Server Worker
  
• sessão:o  nome de sessão é o nome de usuário passado ao comando Open datastore.

No exemplo abaixo, se executam dois processos para a mesma sessão:

Propriedades ORDA relativas ao trancamento de entidades e transações são geradas no nível de processo em datastore remotas, como no modo cliente/servidor ORDA:

• Se um processo tranca uma entidade de uma datastore remota, a entidade é trancada para todos os outros processos, mesmo quando estes processos partilharem a mesma sessão (ver Trancar Entidades). Se várias entidades apontarem ao mesmo registro forem trancadas em um processos, devem ser destrancados no processo para poder remover a tranca. Se uma fechadura foi colocada em uma entidade, a fechadura é removida quando não houver mais referências á esta entidade na memória. 
• Transações podem ser iniciadas, validadas ou canceladas de forma separada para cada datastore remota  usando os métodos dataStore.startTransaction( ), dataStore.cancelTransaction( ), e dataStore.validateTransaction( ). Eles não impactam outras datastores. 
• Comandos na linguagem clássica 4D (START TRANSACTION, VALIDATE TRANSACTION, CANCEL TRANSACTION) só se aplicam à datastore principal (retornado por ds).
• Se uma entidade de uma datastore remota é retida por uma transação em um processo, outros processos não podem atualizá-la, mesmo se estes processos dividirem a mesma sessão. 
• Trancas nas entidades são removidas e transações são restabelecidas:
  • quando o processo é interrompido.
  • quando a sessão é fechada no servidor
  • quando a sessão é interrompida a partir da janela de administração de servidor.

Uma sessão é fechada automaticamente por 4D quando não houver atividade durante o período de timeout. O tempo de espera normal é 60 min, mas o valor poder ser modificado usando o parâmetro connectionInfo do comando Open datastore . 

Se uma petição for enviada para a datastore remota depois que a sessão for fechada, é automaticamente recriada se possível (licença disponível, servidor não parou...) Entretanto, lembre que o contexto da sessão relativo a locks e transações é perdido (ver acima).

O objeto del armazém de dados em si não pode ser copiada como um objeto: