Harbour - SQLMIX x SQLRDD

[aferra]

Grato Itamar, irei estudar o que passou...

[Itamar M. Lins Jr.]

Eu não disse para trazer 100 mil registros no Browse, eu disse para abrir uma tabela que tenha 100 mil registros ou mais. Itamar, você não entende o que você mesmo diz e nem lê, você não lê direito.

Só essa explicação que faltou. Vamos lá!

1)Para quem trabalha com SQL não importa se a tabela tem 1 ou 1.000.000.000 de registros
1.a) Não existe abrir tabela. Apenas solicitamos algo e o resultado vem. Só isso!
2)Não usamos DbGotop(),DBSEEK(), nem DbAppend()... Isso é para DBF!

É 100% ARRAY o tempo todo!!!

Nos Browses(IE/Firefox) da vida usamos um botão para trazer mais resultados. Limitamos isso a BOTÕES. <Antetior> <Próximo> nisso traz os resultados da consulta.

Por exemplo, quando vc escreve: "use clientes", o SQLRDD transcreve p/ isso!

Código: Selecionar todos

21676  01/05/15 16:12:53 SELECT A.* FROM [PRXA_WKLADY_WOBR] A  WHERE 1 = 0 /* Open Workarea */ 

Aqui um log, completo do SQLRDD.

Código: Selecionar todos

Here is sql commands log from SQLLOG.DBF:

........
  21645  01/05/15 16:12:53 SELECT * FROM [PRXA_WKLADY_WOBR] WHERE 0 = 2
  21646  01/05/15 16:12:53 COMMIT
  21647  01/05/15 16:12:53 COMMIT
  21648  01/05/15 16:12:53 DROP TABLE [PRXA_WKLADY_WOBR] /* create table */
  21649  01/05/15 16:12:53 COMMIT
  21650  01/05/15 16:12:53 DELETE FROM SR_MGMNTINDEXES WHERE TABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe index info */
  21651  01/05/15 16:12:53 COMMIT
  21652  01/05/15 16:12:53 DELETE FROM SR_MGMNTTABLES WHERE TABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe table info */
  21653  01/05/15 16:12:53 COMMIT
  21654  01/05/15 16:12:53 DELETE FROM SR_MGMNTLANG WHERE TABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe table info */
  21655  01/05/15 16:12:53 COMMIT
  21656  01/05/15 16:12:53 DELETE FROM SR_MGMNTCONSTRAINTS WHERE TABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe table info */
  21657  01/05/15 16:12:53 COMMIT
  21658  01/05/15 16:12:53 DELETE FROM SR_MGMNTCONSTRAINTS WHERE SOURCETABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe table info */
  21659  01/05/15 16:12:53 COMMIT
  21660  01/05/15 16:12:53 DELETE FROM SR_MGMNTCONSTRTGTCOLS WHERE SOURCETABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe table info */
  21661  01/05/15 16:12:53 COMMIT
  21662  01/05/15 16:12:53 DELETE FROM SR_MGMNTCONSTRSRCCOLS WHERE SOURCETABLE_ = 'PRXA_WKLADY_WOBR' /* Wipe table info */
  21663  01/05/15 16:12:53 COMMIT
  21664  01/05/15 16:12:53 SELECT * FROM [PRXA_WKLADY_WOBR] /* check dropped table */
  21665  01/05/15 16:12:53 COMMIT
  21666  01/05/15 16:12:53 COMMIT
  21667  01/05/15 16:12:53 CREATE TABLE [PRXA_WKLADY_WOBR] (    [CZLO_KEY] VARCHAR (36) ,
   [MSK_KEY] VARCHAR (46) ,
   [NP] CHAR (8) ,
   [TO] CHAR (10) ,
   [MR] CHAR (2) ,
   [RR] CHAR (4) ,
   [KO] VARCHAR (30) ,
   [KP] VARCHAR (30) ,
   [ST] NUMERIC (1,0) ,
   [SR] CHAR (3) ,
   [SD] CHAR (2) ,
   [ND] NUMERIC (6,0) ,
   [NK] NUMERIC (4,0) ,
   [KW] NUMERIC (14,2) ,
   [DD] DATE NULL ,
   [TP] DATE NULL ,
   [DR] DATE NULL ,
   [DK] DATE NULL ,
   [UW] VARCHAR (30) ,
   [PF] VARCHAR (25) ,
   [DKR] BIT,
   [USR] CHAR (1) ,
   [SR_RECNO] NUMERIC (15,0) IDENTITY,
   [SR_DELETED] CHAR (1)  NOT NULL
 )
  21668  01/05/15 16:12:53 COMMIT
  21669  01/05/15 16:12:53 CREATE  CLUSTERED INDEX PRXA_WKLADY_WOBR_SR ON [PRXA_WKLADY_WOBR]([SR_RECNO])  /* Unique Index */
  21670  01/05/15 16:12:53 COMMIT
  21671  01/05/15 16:12:53 DELETE FROM SR_MGMNTTABLES WHERE TABLE_ = 'PRXA_WKLADY_WOBR'
  21672  01/05/15 16:12:53 COMMIT
  21673  01/05/15 16:12:53 INSERT INTO SR_MGMNTTABLES ( TABLE_ , SIGNATURE_, CREATED_, TYPE_, REGINFO_ ) VALUES ( 'PRXA_WKLADY_WOBR','MGMNT 1.72', '2015010516:12:53','TABLE',' ' )
  21674  01/05/15 16:12:53 COMMIT
  21675  01/05/15 16:12:53 SELECT MAX( [SR_RECNO] ) FROM [PRXA_WKLADY_WOBR] /* Counting Records */
  21676  01/05/15 16:12:53 SELECT A.* FROM [PRXA_WKLADY_WOBR] A  WHERE 1 = 0 /* Open Workarea */
  21677  01/05/15 16:12:53 COMMIT
  21678  01/05/15 16:12:53 SELECT TABLE_,SIGNATURE_,IDXNAME_,IDXKEY_,IDXFOR_,IDXCOL_,TAG_,TAGNUM_ FROM SR_MGMNTINDEXES WHERE TABLE_ = 'PRXA_WKLADY_WOBR' ORDER BY IDXNAME_, TAGNUM_
  21679  01/05/15 16:12:53 SELECT TOP    12 A.* FROM [PRXA_WKLADY_WOBR] A  ORDER BY A.[SR_RECNO]  /* GoTop */
  21680  01/05/15 16:12:53 COMMIT
..............

OLD LIB
USE PRXA_WKLADY_WOBR
? LEN(STR(KW))
14
NEW LIB (2014.08)
USE PRXA_WKLADY_WOBR
? LEN(STR(KW))
17

BUT...

OLD LIB
USE PRXA_WKLADY_WOBR
? LEN(STR(ND))
6
NEW LIB (2014.08)
USE PRXA_WKLADY_WOBR
? LEN(STR(ND))
6

SO I SUPPOUSE PROBLEM HAS SOMETHING COMMON WITH DECIMALS :)

Regards
Andrzej Morgiewicz 

Tudo que nós escrevemos usando sintaxe para acesso a DBF ele transcreve para SQL.
Para o pessoal que já usa SQL isso é aberração... Nem passa por a cabeça deles isso.

É absolutamente diferente do SQLMIX. Não tem nada a ver.

Imagine ai o pessoal novo que está chegando agora no mercado saindo da faculdade ?
Vai aprender SQLRDD ? para trabalhar com PostGres ? As pessoas já sabem usar SQL é um empecilho a menos.
Vai querer usar a SQLMIX ou o DRIVER do Rodrigo Moreno, isso sim.

Já para outras pessoas do xBase o SQLRDD é uma mão na roda, uma maravilha.

Cada um escolha suas ferramentas e seja feliz, agora não é porque é livre(GPL) que é ruim.
No caso a pessoa que fez, fez para uso dela e teve a nobreza de disponibilizar p/ outras pessoas, tem erros ? sim podem existir, tem limitações ? depende do ponto de vista de cada um, ele fez p/ atender os problemas dele, não fez p/ vender, nem para atender problemas particulares dos outros, aqui estamos em comunidade, cada um ajuda da forma que pode.
Segue explicação do autor da SQLMIX de como ela funciona.

Simple SQL Interface for Harbour

1. Introduction

Simple SQL interface implements accessing SQL query result via RDD
interface. It is not intended to be replacement for "transparent" move of
DBFCDX application to SQL world.

I want to discuss this in more detail. Many current RDDs for SQL servers
(ex. SQLRDD from xHarbour.com) tries to make a feeling you are working with
DBF file, but not with SQL database. SQL server does not support many
features, ex. RecNo(), deleted flag, file locks, record locks. These RDDs
are emulating these features to make feeling of DBF. Deleted() function is
emulated by creating additional table columns to store delete flag. Some
"hidden system" tables are used to register locking operations and emulate
record and file locks in DBF style. The idea of SQL query is also lost. If
you do a simple loop

dbUseArea( , "select * from my_table" )
DO WHILE ! Eof()
somefunc( FIELD->some_sql_field )
dbSkip()
ENDDO

RDD usualy will read SQL rows in portions, let's say 100 records per query.
So, hidden queries are generated. If you are using indexes these queries
are really complicated. Let's have index on FIELD1 + Str( FIELD2 ). A seek
to value cValue1 + Str( nValue2 ) will generate a query like:

SELECT * FROM my_table
WHERE (FIELD1 == cValue1 and FIELD2 >= nValue2) or FIELD1 > cValue1
ORDER BY FIELD1, FIELD2, _RECNO
LIMIT 100

After evaluation of first 100 cached records, next query will be generated:

SELECT * FROM my_table
WHERE (FIELD1 == cLastField1 and FIELD2 == nLastValue2 and _RECNO > nLastRecno) or
(FIELD1 == cLastField1 and FIELD2 > nLastValue2) or
FIELD1 > cLastValue1
ORDER BY FIELD1, FIELD2, _RECNO
LIMIT 100

To optimize these queries the SQL index expresion should be
"FIELD1,FIELD2,_RECNO", but not "FIELD1,FIELD2" as written in INDEX ON
command.

"Simple SQL interface" is too long to repeat every time I want to
address this library. I'll also use acronym "SSI" to address it.

The idea of SSI is different. It does not make hidden queries. All
queries should be made explicitly by programmer. SSI gives access to query
result via RDD interface, it does not tries to emulate DBF and be
"plug-and-play" solution for DBF to SQL migration. If you do

dbUseArea( , "select * from my_table")

all query (it could contain millions of records!) will be cached.

The features of SSI approach are:

- It's possible to access SQL database of other applications. Other
applications usualy does not follow agreement of "plug-and-play" SQL drivers
about additional DELETED column, _RECNO in the end of index expression, etc.
Access of SQL database of other applications is sometimes not possible.

- It's query oriented. That means a simple DO WHILE ! Eof() loop will iterate
each records once and only once. This is not true for "plug-and-play" SQL
drivers, if indexing is used. Just like in the case of loop over DBF file.
It is not guaranteed that all records are included! Yes! If key value of the
first record in index is changed to be the last record in index during the
phase of record processing, DO WHILE ! Eof() loop will iterate only this
single records even if the database contains millions of records. Your sould
do FLock() on DBF to guarantee the records are not changed. Do you use FLock()
before readonly DO WHILE ! Eof() loops?

2. Architecture

+-------------+
| |
| SQLMIX RDD |
| |
+-------------+
| ^
V |
+-------------+ +---------+
| |--->| |
| SQLBASE RDD | | SDD |
| |<---| |
+-------------+ +---------+


SQLBASE RDD implements basic functionality for accessing SQL query result
via RDD interface. This RDD could be used, if indexing of query result is not
necessary or all indexing is done by SQL server (by using ORDER BY clause).

SQLMIX RDD implements indexing of query result. This indexing is not
related to SQL server ORDER BY clause. SQLMIX do indexing of the query on the
client side.

SDD is acronym for Sql Database Driver. RDD is used to implement access
of different database formats like DBF, SDF, etc. SDD is used to implement
access of different SQL databases. Every SQL server (MySQL, PostgreSQL, etc.)
has a corresponding SDD. SDD driver implements a specific part of data
exchange interface between SQLBASE and SQL server.



3. Modifying database

SSI presents a query result via RDD interface and generates no hidden
SQL queries. So, how database can be changed? Does dbAppend() and FieldPut()
works, or is it readonly SQL interface?
dbAppend(), FieldPut() and other similiar functions work on cached query
result, i.e. query can be appended by new rows and field values can be
changed, but SQL database is not changed. dbCreate() function can also be
used to create an "empty query result" but no table is created on SQL server.
So, SSI can also be used as implementation of "array RDD".
The programmer must call SQL command explicitly to modify SQL tables.
SSI provides a method to detect which cached rows was changed or appended.

Saudações,
Itamar M. Lins Jr.

[sygecom]

Só essa explicação que faltou. Vamos lá!

1)Para quem trabalha com SQL não importa se a tabela tem 1 ou 1.000.000.000 de registros
1.a) Não existe abrir tabela. Apenas solicitamos algo e o resultado vem. Só isso!

É 100% ARRAY o tempo todo!!!

Entendi, a TOTVS que é a maior empresa de Software da América Latina, faz também tudo errado, sei.

Você está olhando apenas para um simples SELECT agora faça algo mais complexo usando mesmo SQL para vários banco de dados(POSTGRESQL, ORACLE, MYSQL, FIREBIRD e etc...) ai vamos ver como você unifica tudo, vai morrer escrevendo IF para cada banco de dados.

Código: Selecionar todos

2)Não usamos DbGotop(),DBSEEK(), nem DbAppend()... Isso é para DBF!

Sim, nem pode usar, não funciona !!! kkkkk nada é por acaso.

[Itamar M. Lins Jr.]

Entendi, a TOTVS que é a maior empresa de Software da América Latina, faz também tudo errado, sei.

Depois eu que não sei ler...
Isso foi p/ garantir o LEGADO, nos bons tempos da Microsiga era tudo DBF! Até o Protheus 10 acredito que trabalha com DBF via ADS ou MSSQL que é o SGBD padrão.

vai morrer escrevendo IF para cada banco de dados.

Porquê ? se o povo do xHarbour.com não morreu ? ou será que morreu até hoje escrevem if´s ?? Não sabe o que é padrão ANSI SQL...

Sim, nem pode usar, não funciona !!! kkkkk nada é por acaso.

Não entendeu de novo ... deixa prá lá. A pessoa acredita que só existe sintaxe xBase p/ trabalhar com SGBD´s fazer o quê ?

Saudações,
Itamar M. Lins Jr.

[janio]

Pra quem tá acostumado com dbf's... muito bom aprender esses conceitos sobre SQL!

Vlw Itamar!

Janio

[Itamar M. Lins Jr.]

Pra quem tá acostumado com dbf's... muito bom aprender esses conceitos sobre SQL!

Pois é, DBF é DBF e SQL é SQL, são conceitos/usos totalmente diferentes.
O correto é a pessoa fazer um curso para poder saber como é a filosofia de como trabalhar com SQL.
Aprender, ter uma visão correta do MUNDO do SGBD.
A visão que temos a partir do DBF é muito limitada, não usamos nada dos antigos comandos/funções que usamos do DBF. Por isso simular DBF dentro de um motor SGBD é limitar demais o seu uso.
Quem quer migrar é melhor redesenhar tudo, estudar, não usamos OrdWildSeek, Set Filter to, DbSelectArea(), OrdSetFocus(),OrdScope()... nada disso existe nos comandos SQL.
Simular comandos DBF no SQL é pegar uma FERRARI, para andar na estada da roça. Dirigir avião debaixo d'água.
STORED PROCEDURES, Triggers, INNER JOIN, LEFT JOIN, etc... o pessoal do DBF nem sabe o que é isso, campos diferentes, replicação...
E uma das coisas mais importantes! Database Diagrams, RELACIONAMENTOS ENTRE TABELAS! isso é primordial.
http://www.devmedia.com.br/criando-rela ... rver/24453

Então não é só usar o SQLRDD que irá fazer todo esse trabalho, no meu modo de ver é varrer sujeira p/ debaixo do tapete.Procrastinar o verdadeiro aprendizado em SQL.
Quando o pessoal do SQLRDD começa a usar os comandos do SQL, não é mesma coisa que usar o SQLMIX ? Como ponte p/ aprendizado etc.. mas não como meta final, se prender no SQLRDD, como se tudo dependesse dele. SQLRDD não é o Santo Graal, é mais uma ferramenta como tantas outras.

Saudações,
Itamar M. Lins Jr.

[janio]

Realmente, pra quem usa comandos SQl (frise-se), não ha muita diferença entre SQLRDD e SQLMIX! A diferença seria que no SQLRDD vc evita os if's para cada banco de dados que for usar. Mas como já foi dito aqui... vc não usa 5 SGBD diferentes... vc escolhe um e passa a usar quase que exclusivamente aquele! A conexão com outros SBGD seria apenas em casos de migração de dados de outros sistemas para o nosso.

Agora para comandos xbase em SBGD, como é o meu caso que uso Mediator... realmente esses RDD's são uma mão na roda. Tem a questão de 'limitar' o potencial do SGBD... vai de cada um. Eu, por exemplo, ainda não tenho pego casos de lentidão em meu sistema, mesmo em casos de bases de dados enorme (9gb)

[Itamar M. Lins Jr.]

vc evita os if's para cada banco de dados que for usar.

Não! isso é apenas para comandos do xBase! Nos comandos SQL quem faz a QUERY somos nós mesmos. Então vai ter que usar IF´s de qualquer forma para SQL.

casos de lentidão em meu sistema,

Não é apenas isso, acredito que não fica lento. São as outras coisas que deixamos de ter ao usarmos a técnica do DBF dentro do SGBD.
Estamos abrindo mão de melhores possibilidades.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Pois é, DBF é DBF e SQL é SQL, são conceitos/usos totalmente diferentes.
O correto é a pessoa fazer um curso para poder saber como é a filosofia de como trabalhar com SQL.

Só pra adiantar sobre o curso:

SQL = Structured Query Language, é uma linguagem estruturada pra resultados
DBF = Banco de dados em formato DBF

São coisas distintas, o mesmo que comparar DBF e linguagem xBase.

Acho que ele se confundiu, e quis dizer base de dados local e base de dados cliente/servidor.

Mas pra quem quiser começar testando SQL com DBF, aqui a string de conexão que usava no VB, compatível com Clipper + SIXCDX:

Código: Selecionar todos

Case "ADSLOCAL"
    cString = "Provider=Advantage.OLEDB.1;" & _
    "Mode=Share Deny None;" & _
    "Show Deleted Records in DBF Tables with Advantage=False;" & _
    "Data Source=" & Sistema.PathDefault & ";Advantage Server Type=ADS_Local_Server;" & _
    "TableType=ADS_CDX;Security Mode=ADS_IGNORERIGHTS;" & _
    "Lock Mode=Compatible;" & _
    "Use NULL values in DBF Tables with Advantage=True;" & _
    "Exclusive=No;Deleted=No;"

[Itamar M. Lins Jr.]

Ola!
DBF no sentido de usarmos os comandos de manipulação, Dbcreate, Dbseek, DbGoTop... que é uma pequena parte dos comandos xBase, agora com o Harbour foram mais ampliados e esses comandos não existem na linguagem SQL.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Uma explicação não técnica, apenas pra dar uma idéia sobre cliente/servidor.

Imagine o banco de dados no servidor ou internet.
Digamos que o bloco de comunicação da rede/internet seja de 10KB, vai transferir blocos de 10kb.

Imagine uma tela de pedidos, um pedido com 10 itens, onde voce vai pegar o pedido, os dados do cliente, cada produto dos pedidos, e também consultar a descrição dos produtos do pedido.
pedido + cliente + 10 x produtos do pedido + 10 x produtos (pra descrição)
Serão 22 consultas ao banco de dados, equivalente a 220kb.

Com cliente/servidor, pode pedir tudo isso de uma vez, e de repente o resultado ocupa 10kb, portanto 22 vezes mais rápido.

E imagine no caso de filtro, onde vém todo o banco de dados pra escolher o que quer.
Digamos que o banco tem 1.000 registros, ocupando 10mb, passando pela rede ou internet, mesmo quando só precisa de 1 registro.

Com cliente/servidor, pode pedir já somente o que quer, 1 registro ocupando o bloco de 10kb, 1.000 vezes mais rápido.

Tem também o acesso a índice, que acaba dobrando a quantidade de blocos, e se for internet tem também a variação da internet. Isso não acontece com cliente/servidor.

A diferença básica de cliente/servidor é essa: ao invés de trazer o banco de dados até o terminal, o servidor é que faz o trabalho pesado, e entrega ao terminal somente o que interessa, pronto pra uso.

As RDDs existentes no Harbour permitem trabalhar com cliente/servidor como se fosse com DBF, registro a registro, do modo demorado, então podem acabar sendo até mais lentas que DBF. A vantagem é ter o aplicativo convertido instantaneamente.
Então, depois de adotar alguma solução desse tipo, vai ter que fazer os ajustes pra ganhar velocidade, pra trabalhar como cliente/servidor mesmo, e já trazer tudo pronto do servidor.

A proporção não é essa que coloquei, mas acho que explica bem a diferença.
E a consulta ao servidor costuma ser por comandos SQL, por isso é comum chamarem isso de SQL.

Acho que isso serve pra mostrar que apenas mudar pra cliente/servidor não vai deixar mais rápido.

Já tem ganho no sentido de que apenas o servidor vai mexer na base de dados. Os terminais apenas vão pedir ou enviar as informações de/para o servidor, isso já evita problemas de queda de energia nos terminais, por exemplo.
Aquilo de parar todo mundo pra reindexar.... já era, não existe mais isso
Aquilo de parar todo mundo pra acrescentar um campo novo... já era, não existe mais isso.
Aquilo de abrir arquivo, abrir índice, escolher ordem... já era, não existe mais isso.
Mas as vantagens completas, só depois de realmente ajustar o aplicativo pra cliente/servidor.

Qual seria a outra opção?
Alterar todo o aplicativo pra "SQL" e só no final colocar em uso.
Então, melhor adotar a solução alternativa

Até aqui fui teórico, tudo depende se a SQLMIX funciona do jeito que parece.

Uma dúvida:
Essa SQLMIX deixa fazer APPEND, DELETE, GOTO TOP ou é igual RDDADO?
Qual seria a vantagem sobre ADO?

Esquece... reli tudo e vi que já foi explicado.
É igual RDDADO, apenas pra consulta.
A vantagem sobre ADO é... usar igual DBF, mesmo que somente pra consulta.

Funciona o GOTO TOP quando a consulta está vazia?
É que senão não funciona o tbrowse().

Pera aí....
Então convém alertar ao usuário o seguinte:
Vai ter que abrir e fechar os arquivos toda hora, senão as atualizações ao banco de dados não serão vistas.
Ao abrir o arquivo, só vai enxergar o que existir ali naquele momento e nada novo, mesmo horas depois, e não ser que reabra o arquivo.
É isso mesmo?

[janio]

Muito bem, José Quintas! :)Pos

Tbm gostaria de ver as respostas para essas questões que vc levantou. Vamos ver o que dirão aqueles que já usam!

Janio

[Itamar M. Lins Jr.]

Já foram respondidas.

Com o SQLMIX temos SKIP, GOTO, mas na tabela virtual no resultado da QUERY, podemos apaga-la que não afeta nada na tabela MATRIZ, só temos acesso de leitura e gravação via comandos SQL, SELECT, INSERT, DROP...

É a mesma coisa p/ quem usa PHP, JAVA... Ninguém fica remexendo no resultado da query.
A QUERY(questão) é feita, "SELECT * FROM clientes...", vem o resultado, digamos a aQuery(resposta) vc vai gravar e adicionar no resultado ? ou na tabela que gerou o resultado ?
INSERT INTO é na tabela de nome CLIENTES, não na QUERY(resultado da pergunta), que com SQLMIX é um ARRAY igualzinho a uma estrutura DBF.

DBUSEAREA( .T.,"SQLMIX", "select * from dbo.PROD_PESQ", "xx" ) // o Resultado se chama "XX", posso dar append, index, seek... é tudo na memoria RAM, não está sendo gravado nada no HD.
Se eu precisar gravar algo eu preciso usar comandos SQL "UPDATE, INSET INTO"
http://www.linhadecodigo.com.br/artigo/ ... elect.aspx
Essa é a facilidade do SQLMIX, pois podemos navegar no resultado, adicionar, alterar, e depois executar os comandos SQL p/ gravação FISICA da tabela.

Quando as outras perguntas por exemplo:

Então convém alertar ao usuário o seguinte:
Vai ter que abrir e fechar os arquivos toda hora, senão as atualizações ao banco de dados não serão vistas.
Ao abrir o arquivo, só vai enxergar o que existir ali naquele momento e nada novo, mesmo horas depois, e não ser que reabra o arquivo.
É isso mesmo?

Por isso é outro paradigma programar com bancos de dados relacionais.
Tem gatilhos(triggers), stored procedures.... etc, que é disparado enquanto uma tabela é modificada, fazendo refresh na tela, como vocês pensam que funciona um site ? submarino por exemplo ? Ou uma requisição que fazemos no site dos correios p/ pegar o CEP ? tem que estudar muito ler, p/ aprender os novos conceitos.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

É a mesma coisa do DBF.
Por exemplo, tem 10 pessoas modificando, incluindo, a base de dados "estoque.dbf" em um tbrowse() não fica lá piscando fulano alterou isso, beltrano adicionou aquilo... Fica estático! só depois que damos um refresh() os dados alterados são mostrados. Com SQL fazemos a mesma coisa, um refresh(), pode ser por exemplo um comando "SELECT * estoque from WHERE... LIMIT..." Colocamos um botão de REFRESH, com SQLMIX, ele vai lá na TABELA faz a requisição, e mostramos o resultado no tbrowse da mesma forma e é super rápido.
<editado>
Não precisa ficar preocupado se cabe ou não na malha do tbrowse(), é só limitar as linhas de acordo seus testes de velocidade. podemos trazer 100 linhas, 10 linhas... não precisamos ficar preocupados com eof(), bof()... isso é tratado com botões. na programação "CUI " essa do clipper, "if K_DOWN; dbskip()" isso funciona com SQLMIX, mas estamos navegando no resultado. O servidor já esta totalmente desafogado esperando outra requisição. Com DBF ou SIMULANDO um DBF é um paracé de coisas que acontecem, no servidor(pedidos). Com SQLRDD um dbskip(), faz uma requisição no servidor só para isso ! é mole ? Agora imagine ai 200 pessoas navegando em um tbrowse() com SQLRDD ?
Com SQLRDD, dbskip(), dbgoto(), DBSEEK(), vira tudo comandos SQL "SELECT..."
Enquanto SQLMIX, não precisamos de nada disso. Isso ninguém explica na ora de vender!
É só olhar no log do sujeito que postei mais acima.
Um "USE" vira: "SELECT A.* FROM [PRXA_WKLADY_WOBR] A WHERE 1 = 0 /* Open Workarea */"
Um "DGoTop()" vira: "SELECT..." se esses comandos para DBF não existem na linguagem SQL!
É "SELECT p/ todo lado"

Saudações,
Itamar M. Lins Jr.

[janio]

Ok, to gostando!

Aquilo de parar todo mundo pra acrescentar um campo novo... já era, não existe mais isso.

Como é a história? Nao entendi essa parte. Tenho muita manutenção no meu sistema acrescentando campos e criando novos indices. Apesar de usar MySql, uso ainda como se fosse DBF com Mediator. Dae preciso pegar a nova estrutura, criar uma tabela temp, copiar os dados da antiga pra nova (append from), recriar indices... tudo isso com todo mundo parado.

Continuando...

Com SQL precisa bloquear a tabela antes de cada gravação??

Não tem mais commit??

SQL tem indices, mas estes não precisam ser setados... o SBGD ja seleciona o melhor índice conforme a consulta, éh isso??

Um índice INDEX on Str(Codigo) + Dtos(DatEmi)... eh possível? Se não, com seria a criação desses indices em SQL?

Janio