Estimados

Alguna configuracion para pasar el limite de los 2gb en DBF - NTX ?

usado 1.9.335

NO ADS

Como comentario, lo uso con temporales,

Saludos
Osvaldo Ramirez

Hola Osvaldo,

estaría bueno que exista la posibilidad de superar el límitem, siempre he 
asumido que esa barrera es infranqueable ya que en el manual la 
especificación es clara

para paliar esa situación uso 2 dbfs, la principal que tiene los 3 últimos 
años y una secundaria gemela que tiene los años anteriores
en las búsquedas cuando en las consultas paso con la fecha los últimos 3 
años, en el marcado de cambio de fecha cambio el alias,
te paso un ejemplo que me ha ayudado a no reescribir tanto las rutinas

saludos

en este ejemplo tengo un índice con fecha inversa

nAno  := Year( Date() )
nAlias := Select( 'DETAL' )
( nAlias )->( dbSeek( DToS( dFecFin ), .T. ) )
While ( ( nAlias )->( !Eof() ) .And. ( nAlias )->FECHA >= dFecIni )

  ///  lo que sea

   If ( dFec != ( nAlias )->FECHA )
      dFec := ( nAlias )->FECHA )
      ActualizoCartelFecha( dFec )   por ejemplo
      If ( nAno - Year( dFec ) > 3 )
          nAlias := Select( 'DETANT' )
          ( nAlias )->( dbGoTOP() )         arranco en el principio ya que 
por índice sería la posición anterior al alias() principal
   EndIF
   ( nAlias )->( dbSkip() )
EndDO


"Osvaldo Ramirez"  escribió en el mensaje de 
noticias:47e024c9$6e0d6588$4cb0d@news.alaska-software.com...


Estimados

Alguna configuracion para pasar el limite de los 2gb en DBF - NTX ?

usado 1.9.335

NO ADS

Como comentario, lo uso con temporales,

Saludos
Osvaldo Ramirez

Muchas gracias amigo,

El punto es, que dicha informacion es de 42 Dias solamente, ojala fuera 
de años.

Este temporal el cual hablo es una relacion de 42 dias de movimientos de 
entradas y salidas, asi com la existencia de ese dia, de productos de 
farmacia, y analizo producto x producto y veo cuantas entradas, salidas 
y existencias dia por dia, asi junto los 42 dias por producto y 
determinamos con un desviacion estandar el posible stock de inventario a 
tener x producto diario, basado en 42 dias.

Por lo tanto hago todo en un temporal y lo proceso!

La idea que distes de dividir es buena, pero en mi caso, pudiera ser no 
por fecha si no mas bien dividir mi catalogo en 2 archivos y primero 
analizar una parte y luego otra, ya que dicho resultado, va a quedar en 
un solo dbf de 5 o maximo 10mb.


Saludos
Osvaldo Ramirez



On 6/17/2011 2:29 PM, Jorge L wrote:
> Hola Osvaldo,
>
> estaría bueno que exista la posibilidad de superar el límitem, siempre
> he asumido que esa barrera es infranqueable ya que en el manual la
> especificación es clara
>
> para paliar esa situación uso 2 dbfs, la principal que tiene los 3
> últimos años y una secundaria gemela que tiene los años anteriores
> en las búsquedas cuando en las consultas paso con la fecha los últimos 3
> años, en el marcado de cambio de fecha cambio el alias,
> te paso un ejemplo que me ha ayudado a no reescribir tanto las rutinas
>
> saludos
>
> en este ejemplo tengo un índice con fecha inversa
>
> nAno := Year( Date() )
> nAlias := Select( 'DETAL' )
> ( nAlias )->( dbSeek( DToS( dFecFin ), .T. ) )
> While ( ( nAlias )->( !Eof() ) .And. ( nAlias )->FECHA >= dFecIni )
>
> /// lo que sea
>
> If ( dFec != ( nAlias )->FECHA )
> dFec := ( nAlias )->FECHA )
> ActualizoCartelFecha( dFec )  por ejemplo
> If ( nAno - Year( dFec ) > 3 )
> nAlias := Select( 'DETANT' )
> ( nAlias )->( dbGoTOP() )  arranco en el principio ya que por índice
> sería la posición anterior al alias() principal
> EndIF
> ( nAlias )->( dbSkip() )
> EndDO
>
>
> "Osvaldo Ramirez" escribió en el mensaje de
> noticias:47e024c9$6e0d6588$4cb0d@news.alaska-software.com...
>
>
> Estimados
>
> Alguna configuracion para pasar el limite de los 2gb en DBF - NTX ?
>
> usado 1.9.335
>
> NO ADS
>
> Como comentario, lo uso con temporales,
>
> Saludos
> Osvaldo Ramirez

Bueno osvaldo este es un tema de algoritmos, como ya sabras, pero como 
natura non das salamca non presta. y tendras que apelar la famosa frase 
divide y venceras.
es lo yo realizo cuando tengo gran sobrecarga de datos como en tu caso. 
directamente creo una base de datos por dia ej. (st010211.dbf) y alli guardo 
todos mis movimiento. y tendras que tener una base de datos con las 
referencias por dia con el nombre que corresponde a la base a actualizar. es 
un laburo de hormigas pero vale la pena. luego los informes solo es cuestion 
de algoritmos.
oviamente esto cambiara y tendres que modificar bastantes tares en el 
codigo. pero es una solucion a largo tiempo.
un abrazo y espero que soluciones el problema

Gustavo M. Burgos
Rivadavia N 278.
Pcia Roque Saenz Pea - Chaco
Argentina
Fijo 03732-420635
Movil 3732-408559
Burmanspm@arnet.com.ar

On 6/17/2011 5:50 PM, Gustavo M. Burgos wrote:
> Bueno osvaldo este es un tema de algoritmos, como ya sabras, pero como
> natura non das salamca non presta. y tendras que apelar la famosa frase
> divide y venceras.
> es lo yo realizo cuando tengo gran sobrecarga de datos como en tu caso.
> directamente creo una base de datos por dia ej. (st010211.dbf) y alli guardo
> todos mis movimiento. y tendras que tener una base de datos con las
> referencias por dia con el nombre que corresponde a la base a actualizar. es
> un laburo de hormigas pero vale la pena. luego los informes solo es cuestion
> de algoritmos.
> oviamente esto cambiara y tendres que modificar bastantes tares en el
> codigo. pero es una solucion a largo tiempo.
> un abrazo y espero que soluciones el problema
>
Gracias amigo, si, tiene toda la razon, hay que dividir, ahorita estoy 
haciendo pruebas haber de que manera divido, pero como tu dices, si es 
cambio en el codigo.

Saludos
Osvaldo Ramirez

Osvaldo,

En la documentacin de Xbase++ (Gua de Programacin) dice:

DBFDBE_LOCKOFFSET

  Esta constante devuelve o modifica el desplazamiento del rea para los 
bloqueos de registros. El desplazamiento predeterminado es 2 gigabytes. 
Puede modificarse con el fin de garantizar la operacin concurrente de las 
aplicaciones de Xbase++ con las aplicaciones de Clipper. Lo predeterminado 
es 1 gigabyte bajo Clipper 5.01 y 2 gigabytes bajo Clipper 5.2 cuando el 
archivo  NTXLOCK2.OBJ est enlazado con la aplicacin. Cambiar el 
desplazamiento de los bloqueos de registros debera llevarse a cabo 
solamente con un conocimiento detallado del mecanismo de bloqueo para los 
registros. Por ejemplo:

      DbeInfo( COMPONENT_DATA, DBFDBE_LOCKOFFSET, 2 * 10^9 )

  En esta lnea de programa el desplazamiento para los bloqueos de registro 
manipulados por el componente DATA del DBE DBFNTX compuesto se establece en 
2 gigabytes.
  Cuidado: Si el DBFDBE se establece como el componente DATA de un DBE 
compuesto, la alteracin del desplazamiento debe llevarse a cabo tambin 
para el componente ORDER. Por ejemplo, en el DBE DBFNTX compuesto, el DBFDBE 
y el NTXDBE deben tener el mismo desplazamiento para los bloqueos de 
registro. El desplazamiento para el NTXDBE se establece usando la constante 
NTXDBE_LOCKOFFSET.

Hasta ah, la informacin sobre compatibilidad con Clipper de la versin 1.7
Sin embargo, en la versin 1.9, la documentacin se actualiz a:

DBFDBE_LOCKOFFSET

  This constant returns or changes the offset for record locks. The offset 
for record locks determines the maximum size of the DBF table. The default 
offset for record locks is 1.000.000.000 or approx. 1GB. This corresponds to 
the maximum size of a Clipper-compatible DBF table.
  To increase the storage capacity of DBF files to the current maximum of 
~2.4GB, a locking offset of 0x80000000 must be configured. Changing the 
DBFDBE_LOCKOFFSET allows to extend the maximum file capacity of DBF tables 
beyond Clipper's capacity. However these DBF tables cannot be shared safely 
with Clipper due to the different locking offsets used to syncronize 
concurrent operations. The maximum value for DBFDBE_LOCKOFFSET is 
0xFFFFFFFF.

Espero haber sido de ayuda.

Saludos

Jose Luis Otermin
Alaska Software


"Osvaldo Ramirez" <ramirezosvaldo@prodigy.net.mx> escribi en el mensaje 
news:73acb6e8$66a92ea2$51ba5@news.alaska-software.com...
> On 6/17/2011 5:50 PM, Gustavo M. Burgos wrote:
>> Bueno osvaldo este es un tema de algoritmos, como ya sabras, pero como
>> natura non das salamca non presta. y tendras que apelar la famosa frase
>> divide y venceras.
>> es lo yo realizo cuando tengo gran sobrecarga de datos como en tu caso.
>> directamente creo una base de datos por dia ej. (st010211.dbf) y alli 
>> guardo
>> todos mis movimiento. y tendras que tener una base de datos con las
>> referencias por dia con el nombre que corresponde a la base a actualizar. 
>> es
>> un laburo de hormigas pero vale la pena. luego los informes solo es 
>> cuestion
>> de algoritmos.
>> oviamente esto cambiara y tendres que modificar bastantes tares en el
>> codigo. pero es una solucion a largo tiempo.
>> un abrazo y espero que soluciones el problema
>>
> Gracias amigo, si, tiene toda la razon, hay que dividir, ahorita estoy 
> haciendo pruebas haber de que manera divido, pero como tu dices, si es 
> cambio en el codigo.
>
> Saludos
> Osvaldo Ramirez
>

Hola José

mil gracias por la aclaración pero siempre me es confusa esta parte y nunca 
termino de entender si hay más posibilidades de lo que uso .....
no me queda claro si realmente el límite no se puede pasar de 2gb o si

si dado el caso es posible y lo quiero llevar a 4gb, podrías indicarme como 
hacerlo para usar dbfcdx y si habría posibilidad de que expliques los 
cuidados que hay que tener para el lockeo ?

un saludo grande


"José Luis Otermin [Alaska Software]"  escribió en el mensaje de 
noticias:125e2da0$565fa4b7$c5c@news.alaska-software.com...

Osvaldo,

En la documentación de Xbase++ (Guía de Programación) dice:

DBFDBE_LOCKOFFSET

  Esta constante devuelve o modifica el desplazamiento del área para los
bloqueos de registros. El desplazamiento predeterminado es 2 gigabytes.
Puede modificarse con el fin de garantizar la operación concurrente de las
aplicaciones de Xbase++ con las aplicaciones de Clipper. Lo predeterminado
es 1 gigabyte bajo Clipper 5.01 y 2 gigabytes bajo Clipper 5.2 cuando el
archivo  NTXLOCK2.OBJ está enlazado con la aplicación. Cambiar el
desplazamiento de los bloqueos de registros debería llevarse a cabo
solamente con un conocimiento detallado del mecanismo de bloqueo para los
registros. Por ejemplo:

      DbeInfo( COMPONENT_DATA, DBFDBE_LOCKOFFSET, 2 * 10^9 )

  En esta línea de programa el desplazamiento para los bloqueos de registro
manipulados por el componente DATA del DBE DBFNTX compuesto se establece en
2 gigabytes.
  Cuidado: Si el DBFDBE se establece como el componente DATA de un DBE
compuesto, la alteración del desplazamiento debe llevarse a cabo también
para el componente ORDER. Por ejemplo, en el DBE DBFNTX compuesto, el DBFDBE
y el NTXDBE deben tener el mismo desplazamiento para los bloqueos de
registro. El desplazamiento para el NTXDBE se establece usando la constante
NTXDBE_LOCKOFFSET.

Hasta ahí, la información sobre compatibilidad con Clipper de la versión 1.7
Sin embargo, en la versión 1.9, la documentación se actualizó a:

DBFDBE_LOCKOFFSET

  This constant returns or changes the offset for record locks. The offset
for record locks determines the maximum size of the DBF table. The default
offset for record locks is 1.000.000.000 or approx. 1GB. This corresponds to
the maximum size of a Clipper-compatible DBF table.
  To increase the storage capacity of DBF files to the current maximum of
~2.4GB, a locking offset of 0x80000000 must be configured. Changing the
DBFDBE_LOCKOFFSET allows to extend the maximum file capacity of DBF tables
beyond Clipper's capacity. However these DBF tables cannot be shared safely
with Clipper due to the different locking offsets used to syncronize
concurrent operations. The maximum value for DBFDBE_LOCKOFFSET is
0xFFFFFFFF.

Espero haber sido de ayuda.

Saludos

Jose Luis Otermin
Alaska Software


"Osvaldo Ramirez" <ramirezosvaldo@prodigy.net.mx> escribió en el mensaje
news:73acb6e8$66a92ea2$51ba5@news.alaska-software.com...
> On 6/17/2011 5:50 PM, Gustavo M. Burgos wrote:
>> Bueno osvaldo este es un tema de algoritmos, como ya sabras, pero como
>> natura non das salamca non presta. y tendras que apelar la famosa frase
>> divide y venceras.
>> es lo yo realizo cuando tengo gran sobrecarga de datos como en tu caso.
>> directamente creo una base de datos por dia ej. (st010211.dbf) y alli 
>> guardo
>> todos mis movimiento. y tendras que tener una base de datos con las
>> referencias por dia con el nombre que corresponde a la base a actualizar. 
>> es
>> un laburo de hormigas pero vale la pena. luego los informes solo es 
>> cuestion
>> de algoritmos.
>> oviamente esto cambiara y tendres que modificar bastantes tares en el
>> codigo. pero es una solucion a largo tiempo.
>> un abrazo y espero que soluciones el problema
>>
> Gracias amigo, si, tiene toda la razon, hay que dividir, ahorita estoy 
> haciendo pruebas haber de que manera divido, pero como tu dices, si es 
> cambio en el codigo.
>
> Saludos
> Osvaldo Ramirez
>

Me uno mi estimado Jose

Que ponemos y Donde para que un DBF + NTX utilize 4gb, claro sabiendo 
que puede habler problemas con las app de clipper ?

Saludos
Osvadlo Ramirez

Estimados

Hice algunas pruebas con la configuracion de los DBE, pero no di pie con 
bola al tratar de aumentar la capacidad de los DBF.

Mejor segui los consejos, divide y venceras.

Un proceso de mis temporales, ya lo saque, es decir ya esta solucionado.

Muchas gracias por sus tiempos.

Saludos
Osvaldo Ramirez

Osvaldo:

Si de verdad a tu clietne le gustan las estadisticas, entonces te
recomiendo pasar los datos a una gran tablas sqlite ( se supone que maneja
hasta terabytes de datos ) y despues le aplicas este paquete:

http://www.sofastatistics.com/home.php

Con eso tiene todo tipo y color de estadisticas ademas de informes
customizados. 

Si quiere mas que eso que mejor contrate un matemático !!!

Dime amigo, que has logrado hacer con esto ?

Saludos
Osvaldo Ramirez

Hola a todos

luego de haber leído varias veces la explicación de José
creo entender que sólo recuerda que el default del tamaño del archivo es 1gb 
que coincide con la cantidad de registros lokeados y explica como superar 
este límite y llevarlo a 2gb
pero no especifica como creí entender al principio,  que se podía superar 
los 2gb, tema por el cual se ha abierto este hilo

saludos



"Osvaldo Ramirez"  escribió en el mensaje de 
noticias:4e5faec3$48bb2d6c$10f43@news.alaska-software.com...

Estimados

Hice algunas pruebas con la configuracion de los DBE, pero no di pie con
bola al tratar de aumentar la capacidad de los DBF.

Mejor segui los consejos, divide y venceras.

Un proceso de mis temporales, ya lo saque, es decir ya esta solucionado.

Muchas gracias por sus tiempos.

Saludos
Osvaldo Ramirez

Jorge,

Tu segunda lectura fue apropiada.
Hice una prueba simple (adjunto cdigo fuente) cuyos resultados comparto.

Me limit a hacer las pruebas (el banco de pruebas produce verdades 
inapelables) y obtuve un mensaje de error IDSC el cual nos dice que se 
alcanz el lmite.

En mi prueba puse a ejecutar DBAppend() en un bucle que debera haber creado 
una tabla de 2,5 GB.
Sin embargo, el resultado indica que no puede superarse el lmite de 2GB.

Es probable que se deba al diseo del modelo DBF o limitaciones de los 
ndices NTX o CDX.
Recordemos que para 1980 (momento de creacin del diseo DBF) ya 640 Kb era 
MUCHA memoria.

Osvaldo, sugiero uses PostgreSQL que es FREEWARE y slida, porque las dems 
BD no renen AMBAS condiciones.
Adems, PostgreSQL ser el modelo nativo de datos y, por tanto, sers 
compatible con Xbase++ 2.0.

Espero haber sido de ayuda.

Saludos

Jose Luis Otermin
Alaska Software

PD: De todas formas, a la luz de los resultados, he enviado el ejemplo al 
soporte interno para su anlisis.
Todava no est todo dicho 


"Jorge L" <jlborlando@way.com.ar> escribi en el mensaje 
news:251ee70b$6832f0e0$13ed1@news.alaska-software.com...
> Hola a todos
>
> luego de haber ledo varias veces la explicacin de Jos
> creo entender que slo recuerda que el default del tamao del archivo es 
> 1gb
> que coincide con la cantidad de registros lokeados y explica como superar
> este lmite y llevarlo a 2gb
> pero no especifica como cre entender al principio,  que se poda superar
> los 2gb, tema por el cual se ha abierto este hilo
>
> saludos
>
>
>
> "Osvaldo Ramirez"  escribi en el mensaje de
> noticias:4e5faec3$48bb2d6c$10f43@news.alaska-software.com...
>
> Estimados
>
> Hice algunas pruebas con la configuracion de los DBE, pero no di pie con
> bola al tratar de aumentar la capacidad de los DBF.
>
> Mejor segui los consejos, divide y venceras.
>
> Un proceso de mis temporales, ya lo saque, es decir ya esta solucionado.
>
> Muchas gracias por sus tiempos.
>
> Saludos
> Osvaldo Ramirez
> 

Muchas gracias amigo.

Saludos
Osvaldo Ramirez

jose luis te hago una pregunta. si la base de datos esta creada con algun 
utilizario de clipper. lo mismo se puede extender mas alla de los 2 g.
bueno no es una buena pregunta. pero mas vale pregunta que quedarse con la 
duda. saludos

Gustavo M. Burgos
Rivadavia N 278.
Pcia Roque Saenz Pea - Chaco
Argentina
Fijo 03732-420635
Movil 3732-408559
Burmanspm@arnet.com.ar

Hola Gus,

Por lo que tengo entendido, ms all de los 2GB con DBF, no.
Para que Clipper sea compatible, tiene que estar enlazado como dice la 
documentacin, con NTXLOCK2.OBJ, y se podrn compartir tablas de hasta 2GB.

Espero haber sido de ayuda.

Saludos

Jose Luis Otermin
Alaska Software




"Gustavo M. Burgos" <Burmanspm@arnet.com.ar> escribi en el mensaje 
news:22b69dc2$26bdda4c$53db2@news.alaska-software.com...
> jose luis te hago una pregunta. si la base de datos esta creada con algun 
> utilizario de clipper. lo mismo se puede extender mas alla de los 2 g.
> bueno no es una buena pregunta. pero mas vale pregunta que quedarse con la 
> duda. saludos
>
> -- 
> Gustavo M. Burgos
> Rivadavia N 278.
> Pcia Roque Saenz Pea - Chaco
> Argentina
> Fijo 03732-420635
> Movil 3732-408559
> Burmanspm@arnet.com.ar
>

Osvaldo,

Espero hayas extrado algo positivo de todo este hilo.
Mira, si el tamao y performance de la BD es el tema, sugiero usar ODBCDBE y 
PostgreSQL.
La migracin de tablas es sencilla y puedo pasarte el programa que hice para 
migrar las mas.

La sintaxis de acceso, manejo y administracin de tablas es LA MISMA de DBF.

Por supuesto, se puede optimizar al sistema cambiando las aperturas de 
tablas y filtrados (por medio de ndices y ciclos DO...WHILE) a sentencias 
SQL.

Lo que resulta claro es que USAR UNA BD SQL con ODBCDBE lleva algo ms de 2 
hs.

El resto es cuestin de convertir cdigo para superar la velocidad de 
ejecucin actual.

S que intentaste usar PostgreSQL. Qu puedes contar?
Obviamente yo no usara MySQL porque NO es freeware.
Para eso, usara Oracle 10g que s lo es para pocos usuarios.

Espero haber sido de ayuda.

Saludos

Jose Luis Otermin
Alaska Software



"Osvaldo Ramirez" <ramirezosvaldo@prodigy.net.mx> escribi en el mensaje 
news:47e024c9$6e0d6588$4cb0d@news.alaska-software.com...
>
> Estimados
>
> Alguna configuracion para pasar el limite de los 2gb en DBF - NTX ?
>
> usado 1.9.335
>
> NO ADS
>
> Como comentario, lo uso con temporales,
>
> Saludos
> Osvaldo Ramirez