[Firebird-devel] Fwd: [firebird-support] gbak isc error 335545106

2021-12-19 Thread Dimitry Sibiryakov

Dimitry Sibiryakov wrote 19.12.2021 21:19:

Bennie Coetzer wrote 19.12.2021 20:08:

is there any explanation of what the error code means?


   In iberror.h: isc_login_error  = 335545106L
   Corresponding text: "Error occurred during login, please check server 
firebird.log for details".


  BTW after changes in message generator it is not possible to find error by 
GDS code anymore. That's pity.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

2021-12-19 Thread Dmitry Yemanov

19.12.2021 16:04, Mark Rotteveel wrote:

Looked at it again, and being able to get the total row count will work 
for me. Is this information already available, or does this still need 
to be implemented?


Implemented but not yet committed. I will post a pull request tomorrow.

One last thing I was wondering about (but haven't had time to verify): 
what happens with positional updates or deletes when scrolling?


Specifically:
- After an update: does the cursor have the original row content or the 
updated content?


Original.

- After a delete: does the row disappear from the cursor, does the 
cursor retain the original content of the row, or does an 'empty' (e.g. 
all NULL) row exist in the cursor?


The original content is retained.

Basically, it should work the same way as for SELECT ... ORDER BY 
non-indexed-field (where records are cached inside the sort).



Dmitry


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

2021-12-19 Thread Mark Rotteveel

On 08-12-2021 10:13, Dmitry Yemanov wrote:

28.11.2021 14:45, Mark Rotteveel wrote:


We don't have anything like this. Theoretically, we could extend 
IRecordSet with something similar (although it would also require a 
protocol change), but the question is whether it's really needed. 
Personally, I don't see it useful per se. If users want to know a 
number of rows, then perhaps an explicit getRowCount() method would 
be more useful (*). But AFAIU the Java API does not mention it.


(*) not applicable to uni-directional cursors?


The intent of the method is to report the position of the current row. 
The example it is abused by some to get the total size was just an 
illustration of why people would expect a value after requesting the 
last row. But the same would be a problem if people went to last, 
scrolled around and then want to know the current row position.


I was thinking about providing both "current position" and "row count" 
information values for a cursor. Both are doable, however the former has 
some issues:

[..]
3) "row count" makes it possible to know the position after fetchLast() 
and everything else could be calculated locally by the client library, 
thus making the server-supported "current position" totally unnecessary.


Do I miss anything? Could we agree on having only "row count" returned 
via op_info_cursor and leaving "cursor position" (getRow() in Java API) 
up the connectivity library developers?


Looked at it again, and being able to get the total row count will work 
for me. Is this information already available, or does this still need 
to be implemented?


One last thing I was wondering about (but haven't had time to verify): 
what happens with positional updates or deletes when scrolling?


Specifically:
- After an update: does the cursor have the original row content or the 
updated content?
- After a delete: does the row disappear from the cursor, does the 
cursor retain the original content of the row, or does an 'empty' (e.g. 
all NULL) row exist in the cursor?


Mark
--
Mark Rotteveel


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel