Recent changes to bugs

LETO_ERRINTERNAL!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Júlio Elias — Tue, 05 Jul 2016 21:17:00 -0000

Hello friends!

I am using LETODB Server v.2.15b1. I have some problems with leto_errInternal!!!!!!!!!!!! on windows2008 server 32 bits and it lots datas. I extract parts of the LETODB.LOG.

leto_errInternal!!!!!!!!!!!!!!!!!!

05/25/16 11:37:38: Leto DB Server has been started.

Leto DB Server v.2.16b1 ! INIT: DataPath=D:\MLINE, ShareTables=1, MaxUsers=500, MaxTables=5000, CacheRecords=100

DEBUG! new connect 10.1.1.198 (0 : 1 : 1)

DEBUG! new connect 10.1.1.47 (1 : 2 : 2)

DEBUG! new connect 10.1.1.79 (2 : 3 : 3)

DEBUG! new connect 10.1.1.38 (3 : 4 : 4)

DEBUG! new connect 10.1.1.200 (4 : 5 : 5)

DEBUG! new connect 10.1.1.180 (5 : 6 : 6)

DEBUG! new connect 10.1.1.137 (6 : 7 : 7)

DEBUG! new connect 10.1.1.165 (7 : 8 : 8)

DEBUG! new connect 10.1.1.49 (8 : 9 : 9)

DEBUG! new connect 10.1.1.114 (9 : 10 : 10)

DEBUG! new connect 10.1.1.211 (10 : 11 : 11)

DEBUG! new connect 10.1.1.104 (11 : 12 : 12)

DEBUG! new connect 10.1.1.166 (12 : 13 : 13)

DEBUG! close connect 10.1.1.38 VENDAS02 Estoque.EXE users=(3 : 13 : 13), tables=(127 : 130)

DEBUG! new connect 10.1.1.137 (3 : 13 : 13)

DEBUG! close connect 10.1.1.137 LOGISTICA10 Estoque.EXE users=(3 : 13 : 13), tables=(127 : 130)

DEBUG! close connect 10.1.1.114 VAREJO03 MITIE.EXE users=(9 : 12 : 13), tables=(126 : 130)

DEBUG! new connect 10.1.1.98 (3 : 12 : 13)

DEBUG! close connect 10.1.1.98 VAREJO04 Estoque.EXE users=(3 : 12 : 13), tables=(129 : 130)

DEBUG! new connect 10.1.1.98 (3 : 12 : 13)

DEBUG! close connect 10.1.1.98 VAREJO04 Estoque.EXE users=(3 : 12 : 13), tables=(129 : 130)

DEBUG! new connect 10.1.1.98 (3 : 12 : 13)

DEBUG! new connect 10.1.1.104 (9 : 13 : 13)

DEBUG! close connect 10.1.1.49 LOGISTICA02 Estoque.EXE users=(8 : 13 : 13), tables=(124 : 130)

DEBUG! close connect 10.1.1.47 ZENAIDE-PC Estoque.EXE users=(1 : 12 : 13), tables=(124 : 130)

DEBUG! new connect 10.1.1.114 (1 : 12 : 13)

DEBUG! new connect 10.1.1.88 (8 : 13 : 13)

DEBUG! new connect 10.1.1.9 (13 : 14 : 14)

DEBUG! new connect 10.1.1.89 (14 : 15 : 15)

DEBUG! new connect 10.1.1.79 (15 : 16 : 16)

DEBUG! close connect 10.1.1.165 CALLCENTER02 Estoque.EXE users=(7 : 16 : 16), tables=(124 : 130)

DEBUG! new connect 10.1.1.110 (7 : 16 : 16)

DEBUG! close connect 10.1.1.110 VENDAS03 Estoque.EXE users=(7 : 16 : 16), tables=(124 : 130)

DEBUG! new connect 10.1.1.110 (7 : 16 : 16)

DEBUG! close connect 10.1.1.104 CAIXA Estoque.EXE users=(9 : 16 : 16), tables=(124 : 130)

DEBUG! close connect 10.1.1.110 VENDAS03 Estoque.EXE users=(7 : 15 : 16), tables=(124 : 130)

DEBUG! close connect 10.1.1.79 FATURAMENTO Estoque.EXE users=(2 : 14 : 16), tables=(124 : 130)

DEBUG! new connect 10.1.1.79 (2 : 14 : 16)

DEBUG! new connect 10.1.1.110 (7 : 15 : 16)

DEBUG! new connect 10.1.1.49 (9 : 16 : 16)

DEBUG! close connect 10.1.1.98 VAREJO04 Estoque.EXE users=(3 : 16 : 16), tables=(127 : 130)

DEBUG! close connect 10.1.1.79 FATURAMENTO SIAD.EXE users=(15 : 15 : 16), tables=(127 : 130)

DEBUG! close connect 10.1.1.79 FATURAMENTO Estoque.EXE users=(2 : 14 : 16), tables=(127 : 130)

DEBUG! new connect 10.1.1.79 (2 : 14 : 16)

DEBUG! new connect 10.1.1.98 (3 : 15 : 16)

DEBUG! new connect 10.1.1.165 (15 : 16 : 16)

DEBUG! new connect 10.1.1.47 (16 : 17 : 17)

DEBUG! close connect 10.1.1.47 ZENAIDE-PC Estoque.EXE users=(16 : 17 : 17), tables=(128 : 130)

DEBUG! new connect 10.1.1.47 (16 : 17 : 17)

DEBUG! new connect 10.1.1.150 (17 : 18 : 18)

DEBUG! new connect 10.1.1.128 (18 : 19 : 19)

DEBUG! close connect 10.1.1.165 CALLCENTER02 Estoque.EXE users=(15 : 19 : 19), tables=(128 : 131)

DEBUG! new connect 10.1.1.165 (15 : 19 : 19)

DEBUG! close connect 10.1.1.165 CALLCENTER02 Estoque.EXE users=(15 : 19 : 19), tables=(128 : 131)

DEBUG! new connect 10.1.1.139 (15 : 19 : 19)

DEBUG! new connect 10.1.1.165 (19 : 20 : 20)

DEBUG! new connect 10.1.1.163 (20 : 21 : 21)

DEBUG! new connect 10.1.1.38 (21 : 22 : 22)

DEBUG! close connect 10.1.1.163 LICITACAO01-PC Estoque.EXE users=(20 : 22 : 22), tables=(128 : 131)

DEBUG! new connect 10.1.1.163 (20 : 22 : 22)

DEBUG! close connect 10.1.1.163 LICITACAO01-PC Estoque.EXE users=(20 : 22 : 22), tables=(128 : 131)

DEBUG! new connect 10.1.1.163 (20 : 22 : 22)

DEBUG! close connect 10.1.1.163 LICITACAO01-PC Estoque.EXE users=(20 : 22 : 22), tables=(128 : 131)

DEBUG! close connect 10.1.1.198 MEDICAL05 Estoque.EXE users=(0 : 21 : 22), tables=(128 : 131)

DEBUG! new connect 10.1.1.198 (0 : 21 : 22)

DEBUG! new connect 10.1.1.163 (20 : 22 : 22)

DEBUG! close connect 10.1.1.110 VENDAS03 Estoque.EXE users=(7 : 22 : 22), tables=(128 : 131)

DEBUG! close connect 10.1.1.89 CAIXA2 Estoque.EXE users=(14 : 21 : 22), tables=(128 : 131)

DEBUG! close connect 10.1.1.163 LICITACAO01-PC Estoque.EXE users=(20 : 20 : 22), tables=(128 : 131)

DEBUG! close connect 10.1.1.150 MEDICAL02 Estoque.EXE users=(17 : 19 : 22), tables=(128 : 131)

DEBUG! new connect 10.1.1.150 (7 : 19 : 22)

DEBUG! new connect 10.1.1.89 (14 : 20 : 22)

DEBUG! new connect 10.1.1.163 (17 : 21 : 22)

leto_errInternal!!!!!!!!!!!!!!!!!!

05/25/16 15:16:29: Leto DB Server has been started.

Leto DB Server v.2.16b1 ! INIT: DataPath=D:\MLINE, ShareTables=1, MaxUsers=500, MaxTables=5000, CacheRecords=100

Please, if you can help me with this problem I will be very happy.

Best Regards,

Júlio.

#13 LetoDb DbSeek() not working with transaction

Alexander S.Kresin — Wed, 17 Jun 2015 08:02:38 -0000

This isn't a but, this is a feature, this is the way as transactions works.

When you process a transaction, all operations, which updates the database, are buffered on the client side and are sent to the server for execution while leto_CommitTransaction().
So, before the leto_CommitTransaction() is complete, the database on the server isn't updated and the records are not added.

LetoDb DbSeek() not working with transaction

Itamar M. Lins Jr. Junior — Wed, 17 Jun 2015 01:50:35 -0000

Function Main( cPath )
Local i, aStru
Field NAME, NUM, INFO, DINFO

REQUEST LETO
RDDSETDEFAULT( "LETO" )
SET DATE FORMAT "dd/mm/yy"

IF Empty( cPath )
cPath := "//127.0.0.1:2812/temp/"
ELSE
cPath := "//" + cPath + Iif( Right(cPath,1) $ "/\", "", "/" )
ENDIF

Leto_fErase( cPath+"test1" )

dbCreate( cPath+"test1", { {"CODIGO","N",5,0}, {"DESCRI","C",10,0} } )
? "File has been created"

USE ( cPath+"test1" ) New
? "File has been opened"

INDEX ON CODIGO TAG CHAVE
? "File has been indexed"

leto_BeginTransaction()

APPEND BLANK
REPLACE CODIGO WITH 1
REPLACE DESCRI WITH "TESTEEEE"

? "Records has been added"

DbGoTop()
? DbSeek( 1 ) // Here bug, not found the record that was just inserted

leto_CommitTransaction()

DbGoTop()
? DbSeek( 1 ) // now found after the commit

?
? "Press any key to finish..."
Inkey(0)

Return Nil

Works fine with DBFCDX and LETO without transaction.

Best regards,
Itamar M. Lins Jr.

#12 index on ... usecurrent bug

Pavel Tsarenko — Fri, 31 Oct 2014 12:40:57 -0000

status: open --> closed

#12 index on ... usecurrent bug

Oleg — Fri, 31 Oct 2014 08:54:47 -0000

The bug is fixed in CVS from 2014-10-29.
Tested. The ticket can be closed.
Thank you.

#12 index on ... usecurrent bug

Pavel Tsarenko — Wed, 29 Oct 2014 14:08:04 -0000

Fixed, please test

#12 index on ... usecurrent bug

Oleg — Wed, 22 Oct 2014 08:05:53 -0000

I tried to change LETODB source to add support of USECURRENT, but found that server at runtime does not know ORDSCOPE values that client assigns.

#12 index on ... usecurrent bug

Oleg — Tue, 21 Oct 2014 13:58:17 -0000

Now look the sources of LetoDB and did not find USECURRENT support at all.
This clause is ignored. Can you add USECURRENT support?

Thank you.

index on ... usecurrent bug

Oleg — Tue, 21 Oct 2014 13:27:20 -0000

LetoDB supports creating indexes with USECURRENT clause, but does not respect the record range specified by ORDSETSCOPE in controlling order.

As said in documentation Clipper 5.3
"USECURRENT specifies that only records in the controlling order--and
within the current range as specified by ORDSETSCOPE()--will be included
in this order. This is useful when you have already created a
conditional order and want to reorder the records which meet that
condition, and/or to further restrict the records meeting a condition.
If not specified, all records in the database file are included in the
order."

Harbour's DBFCDX works as said in documentation.

index on ... usecurrent bug

Oleg — Tue, 21 Oct 2014 13:27:20 -0000

Ticket 12 has been modified: index on ... usecurrent bug
Edited By: Pavel Tsarenko (ptsarenko)
Status updated: u'open' => u'closed'