Can SYSDBA Legacy_UserManager and SYSDBA Srp coexist?
The first time I installed FB 4 (zip), for a while, I saw both as result
of select SEC$USER_NAME, SEC$PLUGIN from sec$users
But after uninstalling and reinstalling I can see only one of them,
depending on the firebird.conf.
Using ...
On 03.09.2021 15:12, Dimitry Sibiryakov wrote:
In the debugger walk up call stack to find out how n got too small
value (or on contrary vlen got too big).
Start from showing definition of the field "ТипВорот" (as per isql
SHOW TABLE and actual values of n and vlen.
I am in the process
On 03.09.2021 15:09, Adriano dos Santos Fernandes wrote:
Is the query just prepared/executed (or just executed directly), or is
it prepared and executed at later moment (after OO do something more)?
That may make a difference. If the later, you may try the former
approach, so if OO is trashing
On 03.09.2021 15:44, Adriano dos Santos Fernandes wrote:
Did you have OO-built isql.exe?
Did you tested OO-built tools outside OO (with ISQL)?
Yes there is in our builddir. But it is unable to open a database,
reporting "Statement failed, SQLSTATE = 08006
Unable to complete network request
On 02/09/2021 13:21, Adriano dos Santos Fernandes wrote:
> On 02/09/2021 13:12, Dimitry Sibiryakov wrote:
>> Adriano dos Santos Fernandes wrote 02.09.2021 17:46:
>>> That makes no sense IMHO and I propose a change to make things simpler
>>> and faster.
>>>
>>> We define error messages (and all
That's pity, because FB4 RN
(https://firebirdsql.org/file/documentation/release_notes/html/en/4_0/rlsnotes40.html)
mention it.
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
02.09.2021 12:17, Mark Rotteveel wrote:
I find the suggestion to make this configurable an interesting one, but
this wouldn't fundamentally resolve the issue you have, it just would
change the compound error of calculation. For example, we followed your
suggestion and provide an option to use
On 9/3/21 3:32 PM, Jiří Činčura wrote:
Hi,
Where I can find fb_info_protocol_version implementation? I'm looking into
https://github.com/FirebirdSQL/firebird/blob/master/src/jrd/inf.cpp and that
case is not there. Nor I can find the fb_info_protocol_version while grep-ing
the sources.
On 03/09/2021 09:44, Adriano dos Santos Fernandes wrote:
>
> Did you have OO-built isql.exe?
>
Sorry for all the "OO" :(!
I mean LO :)
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 03/09/2021 09:36, Mike Kaganski wrote:
> On 03.09.2021 15:29, Adriano dos Santos Fernandes wrote:
>> On 03/09/2021 07:24, Mike Kaganski wrote:
>>>
vcruntime140d.dll!7ffa0f4a1a29()
Engine12.dll!Jrd::Sort::diddleKey(unsigned char * record, bool
direction) Line 916
at
On 03.09.2021 15:29, Adriano dos Santos Fernandes wrote:
On 03/09/2021 07:24, Mike Kaganski wrote:
vcruntime140d.dll!7ffa0f4a1a29()
Engine12.dll!Jrd::Sort::diddleKey(unsigned char * record, bool
direction) Line 916
at
Hi,
Where I can find fb_info_protocol_version implementation? I'm looking into
https://github.com/FirebirdSQL/firebird/blob/master/src/jrd/inf.cpp and that
case is not there. Nor I can find the fb_info_protocol_version while grep-ing
the sources.
--
Mgr. Jiří Činčura
On 03/09/2021 07:24, Mike Kaganski wrote:
>
>> vcruntime140d.dll!7ffa0f4a1a29()
>> Engine12.dll!Jrd::Sort::diddleKey(unsigned char * record, bool
>> direction) Line 916
>> at
>> C:\lo\src\build\workdir\UnpackedTarball\firebird\src\jrd\sort.cpp(916)
>>
Alex Peshkoff via Firebird-devel wrote 03.09.2021 14:18:
That's pity. It is a dead piece anyway.
After such phraze should fiollow: "instead it I suggest bla-bla-bla...".
Wasn't it obvious that I would suggest to get rid of whole firebird.msg and
all code around it leaving only built-in
On 9/3/21 2:29 PM, Mike Kaganski wrote:
ODB is a ZIP; it contains a database/firebird.fbk, from which a FDB is
created when LO opens the DB. I used 'gbak -C firebird.fbk
firebird.fdb' to extract the file initially.
For example database that has left in tmp dir.
Here it is:
On 9/2/21 7:32 PM, Dimitry Sibiryakov wrote:
That's pity. It is a dead piece anyway.
After such phraze should fiollow: "instead it I suggest bla-bla-bla...".
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Mike Kaganski wrote 03.09.2021 14:01:
Definitely a possibility. However, I haven't been yet able to identify where
could that happen.
In the debugger walk up call stack to find out how n got too small value (or
on contrary vlen got too big).
Start from showing definition of the field
On 03/09/2021 09:01, Mike Kaganski wrote:
> On 03.09.2021 14:47, Adriano dos Santos Fernandes wrote:
>> Since you are using embedded, one possible reason would be your process
>> (not FB DLLs) trashing the allocated memory used by FB.
>
> Definitely a possibility. However, I haven't been yet able
On 03.09.2021 14:47, Adriano dos Santos Fernandes wrote:
Since you are using embedded, one possible reason would be your process
(not FB DLLs) trashing the allocated memory used by FB.
Definitely a possibility. However, I haven't been yet able to identify
where could that happen.
--
Best
On 03.09.2021 14:50, Adriano dos Santos Fernandes wrote:
What is the query that causes the crash?
As I mentioned in the initial post:
A specific ODB (a package that contains a FB database) crashes executing a query 'SELECT DISTINCT
"ТипВорот" FROM "ВОРОТА"'
Thanks for looking at this!
--
On 03/09/2021 08:29, Mike Kaganski wrote:
>
>> For example database that has left in tmp dir.
>
> Here it is:
> https://drive.google.com/file/d/1JVutNK0gQ7kZpNi7wOmfeds8dv15f56b/view?usp=sharing
>
What is the query that causes the crash?
Adriano
Firebird-Devel mailing list, web interface
On 03/09/2021 08:44, Mike Kaganski wrote:
> On 03.09.2021 13:37, Mike Kaganski wrote:
>> On 03.09.2021 13:34, Dimitry Sibiryakov wrote:
>>> AFAIK after LO crash the real Firebird database must be left
>>> somewhere in temp directory. Did you used this one for experiments or
>>> extracted a
On 03.09.2021 13:37, Mike Kaganski wrote:
On 03.09.2021 13:34, Dimitry Sibiryakov wrote:
AFAIK after LO crash the real Firebird database must be left
somewhere in temp directory. Did you used this one for experiments or
extracted a fresh copy from the document? Probably, the database got
Mike Kaganski wrote 03.09.2021 13:29:
It is after the crash, and I can't yet query the table in it in isql, because of
"Statement failed, SQLSTATE = 28000
no permission for SELECT access to TABLE" message. I suppose that the crash
didn't close some lock in the DB, and I'm in the process of
On 03.09.2021 13:56, Alex Peshkoff wrote:
On 9/3/21 1:24 PM, Mike Kaganski wrote:
How can I get the metadata to post here? (sorry for a noob question
:)) I can also provide the whole ODB (here it is:
https://drive.google.com/file/d/1UiIJRXuERMFRayPs1GKMAld4ay0EzxFl/view?usp=sharing
)
For
On 03/09/2021 11:49, Mike Kaganski wrote:
> By the way: is there a way to work with isql using UTF-8 on Windows?
Try using Windows Terminal, which is slowly being worked up to replace
the old command terminal. It does properly support UTF8 (still need the
'chcp 65001'), and a few other good
Mike Kaganski wrote 03.09.2021 12:49:
By the way: is there a way to work with isql using UTF-8 on Windows?
From standard command shell the maximum you can do is to execute external SQL
script saved in UTF-8. Something like that:
> isql employee -ch utf-8
Database: employee, User: SD
SQL>
On 9/3/21 1:24 PM, Mike Kaganski wrote:
Sure - here's the stack trace of the moment when VS shows "Exception
thrown at 0x7FFA0F4A1A29 (vcruntime140d.dll) in soffice.bin:
0xC005: Access violation writing location 0x025B7D701000.";
sorry for not including it from start.
Note that
On 03.09.2021 13:37, Mike Kaganski wrote:
On 03.09.2021 13:34, Dimitry Sibiryakov wrote:
AFAIK after LO crash the real Firebird database must be left
somewhere in temp directory. Did you used this one for experiments or
extracted a fresh copy from the document? Probably, the database got
On 03.09.2021 13:34, Dimitry Sibiryakov wrote:
AFAIK after LO crash the real Firebird database must be left
somewhere in temp directory. Did you used this one for experiments or
extracted a fresh copy from the document? Probably, the database got
corrupted somehow after extraction.
Oh -
Mike Kaganski wrote 03.09.2021 12:30:
Please let me cite myself from the original post :)
I tried to extract the database, and use isql tool to perform the same query
interactively - and that works fine. I also have cloned and built FB from its
github repo in DEBUG mode, in the hope that it
Hi Dmitry!
On 03.09.2021 13:29, Dimitry Sibiryakov wrote:
Mike Kaganski wrote 03.09.2021 12:24:
I can also provide the whole ODB
At first, can you reproduce problem with vanilla Firebird and isql?
It can help to understand if Firebird itself has the problem or LO
modifications.
Mike Kaganski wrote 03.09.2021 12:24:
I can also provide the whole ODB
At first, can you reproduce problem with vanilla Firebird and isql?
It can help to understand if Firebird itself has the problem or LO
modifications.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
Hi Alex! Thank you for your reply.
On 03.09.2021 13:07, Alex Peshkoff via Firebird-devel wrote:
On 9/3/21 11:54 AM, Mike Kaganski wrote:
I actually suspect that our integration might do something wrong
initializing the engine, but I am very inexperienced in FB
development, and can't easily
On 9/3/21 11:54 AM, Mike Kaganski wrote:
Hi!
I understand that the question is less than ideal, and I'm sorry for
that.
I'm trying to debug a very strange bug in Firebird built into
LibreOffice (embedded DB functionality). A specific ODB (a package
that contains a FB database) crashes
Hi!
I understand that the question is less than ideal, and I'm sorry for that.
I'm trying to debug a very strange bug in Firebird built into
LibreOffice (embedded DB functionality). A specific ODB (a package that
contains a FB database) crashes executing a query 'SELECT DISTINCT
"ТипВорот"
36 matches
Mail list logo
