Menu
▾
▴
firebird-net-provider — All about development of the MS .Net provider
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(55) |
Dec
(36) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(38) |
Feb
(108) |
Mar
(79) |
Apr
(95) |
May
(64) |
Jun
(130) |
Jul
(146) |
Aug
(121) |
Sep
(96) |
Oct
(149) |
Nov
(161) |
Dec
(113) |
| 2004 |
Jan
(113) |
Feb
(163) |
Mar
(248) |
Apr
(132) |
May
(157) |
Jun
(160) |
Jul
(236) |
Aug
(284) |
Sep
(293) |
Oct
(277) |
Nov
(257) |
Dec
(356) |
| 2005 |
Jan
(203) |
Feb
(190) |
Mar
(220) |
Apr
(165) |
May
(124) |
Jun
(160) |
Jul
(190) |
Aug
(142) |
Sep
(152) |
Oct
(189) |
Nov
(187) |
Dec
(159) |
| 2006 |
Jan
(170) |
Feb
(151) |
Mar
(212) |
Apr
(262) |
May
(226) |
Jun
(196) |
Jul
(223) |
Aug
(165) |
Sep
(163) |
Oct
(348) |
Nov
(225) |
Dec
(141) |
| 2007 |
Jan
(261) |
Feb
(161) |
Mar
(222) |
Apr
(193) |
May
(121) |
Jun
(157) |
Jul
(151) |
Aug
(159) |
Sep
(61) |
Oct
(123) |
Nov
(172) |
Dec
(96) |
| 2008 |
Jan
(104) |
Feb
(138) |
Mar
(131) |
Apr
(131) |
May
(74) |
Jun
(107) |
Jul
(89) |
Aug
(89) |
Sep
(172) |
Oct
(158) |
Nov
(119) |
Dec
(86) |
| 2009 |
Jan
(52) |
Feb
(84) |
Mar
(78) |
Apr
(83) |
May
(54) |
Jun
(79) |
Jul
(60) |
Aug
(62) |
Sep
(50) |
Oct
(147) |
Nov
(50) |
Dec
(70) |
| 2010 |
Jan
(135) |
Feb
(113) |
Mar
(74) |
Apr
(93) |
May
(35) |
Jun
(71) |
Jul
(33) |
Aug
(110) |
Sep
(47) |
Oct
(18) |
Nov
(61) |
Dec
(34) |
| 2011 |
Jan
(46) |
Feb
(47) |
Mar
(25) |
Apr
(24) |
May
(21) |
Jun
(22) |
Jul
(20) |
Aug
(51) |
Sep
(31) |
Oct
(42) |
Nov
(22) |
Dec
(22) |
| 2012 |
Jan
(31) |
Feb
(19) |
Mar
(25) |
Apr
(55) |
May
(16) |
Jun
(28) |
Jul
(33) |
Aug
(25) |
Sep
(32) |
Oct
(25) |
Nov
(52) |
Dec
(35) |
| 2013 |
Jan
(43) |
Feb
(18) |
Mar
(36) |
Apr
(45) |
May
(22) |
Jun
(13) |
Jul
(31) |
Aug
(24) |
Sep
(19) |
Oct
(59) |
Nov
(47) |
Dec
(25) |
| 2014 |
Jan
(27) |
Feb
(15) |
Mar
(38) |
Apr
(10) |
May
(15) |
Jun
(36) |
Jul
(24) |
Aug
(28) |
Sep
(16) |
Oct
(6) |
Nov
(44) |
Dec
(40) |
| 2015 |
Jan
(52) |
Feb
(22) |
Mar
(13) |
Apr
(17) |
May
(22) |
Jun
(36) |
Jul
(18) |
Aug
(41) |
Sep
(71) |
Oct
(60) |
Nov
(49) |
Dec
(43) |
| 2016 |
Jan
(60) |
Feb
(13) |
Mar
(21) |
Apr
(28) |
May
(23) |
Jun
(39) |
Jul
(17) |
Aug
(37) |
Sep
(33) |
Oct
(15) |
Nov
(22) |
Dec
(20) |
| 2017 |
Jan
(27) |
Feb
(40) |
Mar
(48) |
Apr
(19) |
May
(29) |
Jun
(2) |
Jul
(19) |
Aug
(36) |
Sep
(18) |
Oct
(10) |
Nov
(11) |
Dec
(5) |
| 2018 |
Jan
(5) |
Feb
(4) |
Mar
(5) |
Apr
(3) |
May
(4) |
Jun
(17) |
Jul
(7) |
Aug
(7) |
Sep
(12) |
Oct
(8) |
Nov
(2) |
Dec
|
| 2019 |
Jan
(8) |
Feb
(5) |
Mar
(3) |
Apr
(5) |
May
(3) |
Jun
(2) |
Jul
(8) |
Aug
(7) |
Sep
(3) |
Oct
(12) |
Nov
(7) |
Dec
(1) |
| 2020 |
Jan
(8) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(3) |
Aug
(25) |
Sep
(5) |
Oct
(3) |
Nov
(7) |
Dec
(16) |
| 2021 |
Jan
(11) |
Feb
(10) |
Mar
(16) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jiří Č. <ji...@ci...> - 2016-09-13 16:22:15
|
> Is it really neccesssary to get transaction before context:SaveChanges() > in > order to rollback? Yes, if you want to rollback manually. OTOH if there's an error while processing the data, the rollback is automatic. Also take into account that the transaction is only in database, not in context. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Nikolaus K. <par...@gm...> - 2016-09-13 16:15:08
|
Hello, what is the best practice to rollback a failed statement with EF? 1. Working with an entity in a context 2. Putting a raw SQL statement to the database via the context Is it really neccesssary to get transaction before context:SaveChanges() in order to rollback? Thanks Niko |
|
From: Jiří Č. <ji...@ci...> - 2016-09-13 08:06:00
|
More info: http://blog.cincura.net/233571-ado-net-provider-5-1-1-0-for-firebird-is-ready/ . -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: <zab...@gm...> - 2016-09-08 04:59:33
|
What cases? Problem of finalizers that all managed objects you try to reference must be treated as null. If you try to look from this view you'll see that theyre don't do anything Sent from my Windows 10 phone From: Jiří Činčura |
|
From: Jiří Č. <ji...@ci...> - 2016-09-06 16:59:18
|
> In embedded or network part? In embedded I thought I had fixed that In network. The embedded is OK - backed by the SafeHandles - as I wrote. > issues. As for network, they should be eliminated at all IIRC. Agreed. Although there might be a one or two cases where it makes sense, higher up. I just have to review it and think carefully about all the different cases I saw in last few years. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: <zab...@gm...> - 2016-09-06 16:48:25
|
In embedded or network part? In embedded I thought I had fixed that issues. As for network, they should be eliminated at all IIRC. Sent from my Windows 10 phone From: Jiří Činčura |
|
From: <da...@na...> - 2016-09-06 15:57:34
|
Sorry I missed you e-mail but I'm currently on leave. I will return to the office on Monday the 13th of September For all support inquiries please contact the office on +353 (0)1 5253600 or +44 (0)203 4681247 Alternatively please email su...@na... . Kind Regards, David |
|
From: Jiří Č. <ji...@ci...> - 2016-09-06 15:53:17
|
Too late. It's already solved. It was a race condition in Firebird itself. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Jiří Č. <ji...@ci...> - 2016-09-06 15:52:36
|
> What finalizers are you mention? All. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Геннадий З. <zab...@gm...> - 2016-09-06 15:38:31
|
I had catched such random issues by couple of tricks: 1. .trx files that were produced vstest.console. They always have call stack with exception. 2. Unhandled exception handler that creates dump file of process itself and then publish it as artifact. Dump can be opened in Visual Studio, it will look as attached to process. Though I prefer using of WinDbg On 27 August 2016 at 10:28, Jiří Činčura <ji...@ci...> wrote: > Hi *, > > I'm almost closing on compression support. It is stable when I run the > tests on my machine. Multiple time, 32bit, 64bit. But are failing on > AppVeyor. > > To make matters worse it's always different test(s). Check > https://ci.appveyor.com/project/cincura_net/firebirdsql-data-firebirdclient/build/880 > or > https://ci.appveyor.com/project/cincura_net/firebirdsql-data-firebirdclient/build/882 > . Only common piece is that it's always test with compression on (2nd > parameter is True). > > I spent few days trying to guess what's wrong and fixing some things. > But no final luck (I'll not list mine to not skew the thinking). So > maybe some smart people here will have some idea. > > So let's open discussion. Or if you can make it fail on you machine, > that would help as well. > > -- > Mgr. Jiří Činčura > Independent IT Specialist > > ------------------------------------------------------------------------------ > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider |
|
From: Геннадий З. <zab...@gm...> - 2016-09-06 15:35:22
|
What finalizers are you mention? On 29 August 2016 at 11:23, Gerdus van Zyl <ger...@gm...> wrote: > I agree finalizers should not be used to mask or 'fix' incorrect provider > usage. I try to avoid finalizers as much as possible since they run at > unpredictable times causing hard to debug scenarios. > > On Sun, Aug 28, 2016 at 5:40 PM, Jiří Činčura <ji...@ci...> wrote: >> >> Hi *, >> >> Talking about finalizers in my last email. As I was getting through these, >> I found few that are wrong-ish. In 99% cases failing with exception, that's >> just swallowed. Confirmed from runtime. Although in 1% these might be lucky >> I don't think it's correct usage. >> >> What the finalizers are mostly trying to do is something like close >> connection gracefully with server or free some resources on server. >> >> And I believe this is wrong. >> >> First of all, this should be responsibility of developer to have correct >> Dispose calls. Provider should not try to band aid it unless absolutely >> necessary. Which brings me to the next point. The unmanaged resources, where >> the finalizers make sense, are not something on server. We don't manage >> that. Server should handle just fine when developer doesn’t close the >> connection. Though some resources might be wasted. Unmanaged resources >> directly allocated by provider are really a few around Embedded support >> (mostly pointers and pieces of memory for marshalling). And these are >> properly handled by SafeHandle. And finally finalizers introduce reentrancy >> issues (anybody interested in details?) and it's really not correct in >> provider as it grow out of hands. >> >> So in the foreseeable future I'll go through all of them and do massive >> cleanup together with locking cleanup. >> >> It's probably going to cause some issues for some people, but their code >> was wrong before, they were just "lucky". >> >> I believe it will make the code slightly faster and also solve some rare >> bugs, often NREs from finalizer thread. >> >> Of course it will be new major version. >> >> -- >> Mgr. Jiří Činčura >> Independent IT Specialist >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Firebird-net-provider mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider >> > > > > -- > ------------------------------------------------------------------------ > Gerdus van Zyl > www.infireal.com > > ------------------------------------------------------------------------------ > > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider > |
|
From: Jiri C. (JIRA) <tr...@fi...> - 2016-09-05 17:49:35
|
Massive correction of finalizers
--------------------------------
Key: DNET-698
URL: http://tracker.firebirdsql.org/browse/DNET-698
Project: .NET Data provider
Issue Type: Task
Components: ADO.NET Provider
Affects Versions: 5.1.0.0
Reporter: Jiri Cincura
Assignee: Jiri Cincura
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Fabiano R. (JIRA) <tr...@fi...> - 2016-09-01 17:29:33
|
Wrong Migration Sql generated for DropColumn
--------------------------------------------
Key: DNET-697
URL: http://tracker.firebirdsql.org/browse/DNET-697
Project: .NET Data provider
Issue Type: Bug
Components: Entity Framework support
Affects Versions: 5.1.0.0, 5.0.5.0
Environment: Firebird 3, Windows 10 64 bits
Reporter: Fabiano Rezende
Assignee: Jiri Cincura
The migration below
public partial class MyMigration : DbMigration
{
public override void Up()
{
DropColumn("TableName", "ColumnName");
}
}
generated sql: ALTER TABLE "TableName" DROP COLUMN "ColumnName"
but the correct sql should be: ALTER TABLE "TableName" DROP "ColumnName"
The sql as generated raises the error: Token unknown - line 1, column 27. column.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Scot L. (JIRA) <tr...@fi...> - 2016-09-01 15:08:28
|
Windows Trusted Authentication (SSPI) is broken with FB3 and Provider v5
------------------------------------------------------------------------
Key: DNET-696
URL: http://tracker.firebirdsql.org/browse/DNET-696
Project: .NET Data provider
Issue Type: Bug
Components: ADO.NET Provider
Affects Versions: 5.1.0.0, 5.0.5.0, 5.0.0.0
Environment: Windows 7 64 bit, FB3 64 bit
Reporter: Scot Lunsford
Assignee: Jiri Cincura
Starting with version 5.0 of the provider, it appears that windows trusted authentication (SSPI) is broken with FB3 (it works with FB2.5). I can get it to work with a very simple app with versions 4.7 through 4.10. It fails if I use any of the version 5 providers. The error states that "Your user name and password are not defined..."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
System.InvalidOperationException at FirebirdSql.Data.FirebirdClient.dll!FirebirdSql.Data.Client.Managed.XdrStream::Write - Write operations are not allowed by this stream
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: DNET-695
URL: http://tracker.firebirdsql.org/browse/DNET-695
Project: .NET Data provider
Issue Type: Bug
Components: ADO.NET Provider
Affects Versions: 5.1.0.0
Environment: Windows 8, .net 4.5.2
Reporter: André Ziegler
Assignee: Jiri Cincura
While viewing WPR/xperf traces of my application, I see a System.InvalidOperationException in Firebird provider:
https://1drv.ms/i/s!AtziW2MYxY8Si5Zf6ll4eX7CWn_wAg
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Gerdus v. Z. <ger...@gm...> - 2016-08-29 08:24:17
|
I agree finalizers should not be used to mask or 'fix' incorrect provider usage. I try to avoid finalizers as much as possible since they run at unpredictable times causing hard to debug scenarios. On Sun, Aug 28, 2016 at 5:40 PM, Jiří Činčura <ji...@ci...> wrote: > Hi *, > > Talking about finalizers in my last email. As I was getting through these, > I found few that are wrong-ish. In 99% cases failing with exception, that's > just swallowed. Confirmed from runtime. Although in 1% these might be lucky > I don't think it's correct usage. > > What the finalizers are mostly trying to do is something like close > connection gracefully with server or free some resources on server. > > And I believe this is wrong. > > First of all, this should be responsibility of developer to have correct > Dispose calls. Provider should not try to band aid it unless absolutely > necessary. Which brings me to the next point. The unmanaged resources, > where the finalizers make sense, are not something on server. We don't > manage that. Server should handle just fine when developer doesn’t close > the connection. Though some resources might be wasted. Unmanaged resources > directly allocated by provider are really a few around Embedded support > (mostly pointers and pieces of memory for marshalling). And these are > properly handled by SafeHandle. And finally finalizers introduce reentrancy > issues (anybody interested in details?) and it's really not correct in > provider as it grow out of hands. > > So in the foreseeable future I'll go through all of them and do massive > cleanup together with locking cleanup. > > It's probably going to cause some issues for some people, but their code > was wrong before, they were just "lucky". > > I believe it will make the code slightly faster and also solve some rare > bugs, often NREs from finalizer thread. > > Of course it will be new major version. > > -- > Mgr. Jiří Činčura > Independent IT Specialist > > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider > > -- ------------------------------------------------------------------------ Gerdus van Zyl www.infireal.com |
|
From: Jiří Č. <ji...@ci...> - 2016-08-29 08:23:20
|
> A forecast in time for this release Hopefully before end of the year. My current plan, among bug fixes, is roughly: compression > .NET Core > EF Core > finalizers. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Norbert S. G. <ns...@te...> - 2016-08-29 08:18:18
|
> I believe it will make the code slightly faster and also solve some rare > bugs, often NREs from finalizer thread. > > Of course it will be new major version. that is my opinion also. A forecast in time for this release -- Norbert Saint Georges http://tetrasys.fi |
|
From: Jiří Č. <ji...@ci...> - 2016-08-29 06:09:11
|
More info: http://blog.cincura.net/233569-ado-net-provider-5-1-0-0-for-firebird-is-ready/ . -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Jiří Č. <ji...@ci...> - 2016-08-28 15:41:03
|
Hi *, Talking about finalizers in my last email. As I was getting through these, I found few that are wrong-ish. In 99% cases failing with exception, that's just swallowed. Confirmed from runtime. Although in 1% these might be lucky I don't think it's correct usage. What the finalizers are mostly trying to do is something like close connection gracefully with server or free some resources on server. And I believe this is wrong. First of all, this should be responsibility of developer to have correct Dispose calls. Provider should not try to band aid it unless absolutely necessary. Which brings me to the next point. The unmanaged resources, where the finalizers make sense, are not something on server. We don't manage that. Server should handle just fine when developer doesn’t close the connection. Though some resources might be wasted. Unmanaged resources directly allocated by provider are really a few around Embedded support (mostly pointers and pieces of memory for marshalling). And these are properly handled by SafeHandle. And finally finalizers introduce reentrancy issues (anybody interested in details?) and it's really not correct in provider as it grow out of hands. So in the foreseeable future I'll go through all of them and do massive cleanup together with locking cleanup. It's probably going to cause some issues for some people, but their code was wrong before, they were just "lucky". I believe it will make the code slightly faster and also solve some rare bugs, often NREs from finalizer thread. Of course it will be new major version. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Jiří Č. <ji...@ci...> - 2016-08-27 07:28:25
|
Hi *, I'm almost closing on compression support. It is stable when I run the tests on my machine. Multiple time, 32bit, 64bit. But are failing on AppVeyor. To make matters worse it's always different test(s). Check https://ci.appveyor.com/project/cincura_net/firebirdsql-data-firebirdclient/build/880 or https://ci.appveyor.com/project/cincura_net/firebirdsql-data-firebirdclient/build/882 . Only common piece is that it's always test with compression on (2nd parameter is True). I spent few days trying to guess what's wrong and fixing some things. But no final luck (I'll not list mine to not skew the thinking). So maybe some smart people here will have some idea. So let's open discussion. Or if you can make it fail on you machine, that would help as well. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Jiří Č. <ji...@ci...> - 2016-08-22 08:36:11
|
> long as this i not fixed. Thus I would urge you to prioritize this if > possible. Yeah. It pretty much depends on my time. :\ -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Jardar M. <jar...@nd...> - 2016-08-22 08:27:58
|
As the other guy pointed out the connection pool is more or less useless as long as this i not fixed. Thus I would urge you to prioritize this if possible. Best regards Jardar On Mon, Aug 22, 2016 at 8:49 AM, Jiří Činčura <ji...@ci...> wrote: > > Any plans on when this issue will be fixed? > > No exact ETA. > > -- > Mgr. Jiří Činčura > Independent IT Specialist > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider > -- Jardar Maatje Nortek Data Services AS Brugata 1 0168 Oslo tlf: +47 95184034 |
|
From: Jiří Č. <ji...@ci...> - 2016-08-22 06:49:32
|
> Any plans on when this issue will be fixed? No exact ETA. -- Mgr. Jiří Činčura Independent IT Specialist |
|
From: Jardar M. <jar...@nd...> - 2016-08-21 19:04:13
|
Hi Any plans on when this issue will be fixed? 21. aug. 2016 20.55 skrev "Jiří Činčura" <ji...@ci...>: > > Is this the cause, and if so when will this be fixed? > > Check the http://tracker.firebirdsql.org/browse/DNET-668 . That's like > superset of the solution. > > > Also is there any good ways to work around this problem? > > Cleaning the pool is probably the best workaround you can get right now. > > -- > Mgr. Jiří Činčura > Independent IT Specialist > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider > |
211 messages has been excluded from this view by a project administrator.
