from:"Alexander Muylaert\-Gelein"

Re: [Firebird-net-provider] .NET 4 support

2017-01-15 Thread Alexander Muylaert-Gelein

Hi Gerdus


The question is... should "we" be affected by "your" difficulties upgrading 500 
pcs.  I have the same problem, it is even thousands and all running on 
different locations, but we try to manage.  (Failing miserably, but that is 
another story)

I agree with your opinion that you can stay on current implementation and not 
migrate away to all the new features.  If it works, it works, no?


Besides new features and code clean ups... what with bugfixes though.  I don't 
think we can keep on expecting from Jiri to backport all fixes to all version 
all the time.

I rather see Jiri working on the new event system then to keep 4.0 code running.


kind regards


a




Verzonden vanuit Outlook



Van: Gerdus van Zyl 
Verzonden: zondag 15 januari 2017 15:55
Aan: For users and developers of the Firebird .NET providers
Onderwerp: Re: [Firebird-net-provider] .NET 4 support

I am still using 4.0 due to the difficulty upgrading 500+ computers and a 
painful amount of customers still on XP. The downside of desktop software.
That being said the current code is stable and fast in our experience so would 
be happy to stay on the current version until we are ready to upgrade .net 
version.

On 15 January 2017 at 15:11, Jirí Cincura 
> wrote:
Hello *,

reading the
===
As previously announced, starting January 12, 2016 Microsoft will no longer 
provide security updates, technical support or hotfixes for .NET 4, 4.5, and 
4.5.1 frameworks. All other framework versions, including 3.5, 4.5.2, 4.6 and 
4.6.1, will be supported for the duration of their established lifecycle. The 
decision to end support for these versions will allow us to invest more 
resources towards improvements of the .NET Framework.
===

makes me wonder who here is using strictly 4.0, still one year after it's no 
longer supported. ;) It would make my life easier to drop .NET 4 support and 
invest my resources to moving forward faster. 4.5.2+ would still be supported, 
of course.

--
Mgr. Jirí Cincura
Independent IT Specialist


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider




--

Gerdus van Zyl
www.infireal.com
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Firing event when event count is 0

2016-12-16 Thread Alexander Muylaert-Gelein

I say ney.  It doesn’t make sense to raise unraised events.



Sent from Mail for Windows 10



From: Jiří Činčura
Sent: vrijdag 16 december 2016 17:15
To: For users & developers of the Firebird .NET 
providers
Subject: [Firebird-net-provider] Firing event when event count is 0



Hi *,

As I'm now reworking some pieces in events (together with finalizers),
I'm wondering whether it make sense to fire the event for events when
the event count was 0. From outside POV it doesn't make much sense.

What do you think?

--
Mgr. Jiří Činčura
Independent IT Specialist

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Stored procedures etc. in .NET

2016-06-27 Thread Alexander Muylaert-Gelein

Hi Jiri
There is interest on our behalf.  But we will only switch to FB 3... after 
release 2 or something like that.That doesn't mean we are not interested in 
kicking this into motion.

Thanks
Alexander

> From: j...@cincura.net
> To: firebird-net-provider@lists.sourceforge.net
> Date: Mon, 27 Jun 2016 20:51:31 +0200
> CC: firebird-de...@lists.sourceforge.net
> Subject: [Firebird-net-provider] Stored procedures etc. in .NET
> 
> Hi *,
> 
> there's something I've been working on for a few evenings and weekends.
> As you might know, from Firebird 3 there's and interface to write a
> plugin that allows to execute any code as stored procedure, function or
> trigger.
> 
> So why not to have these in .NET, right? I have a working plugin right
> now. Currently only stored procedures are supported. No blobs at the
> moment as well.
> 
> You can check small example at the end of this email.
> 
> Now the important part. Is there enough interest in this to keep working
> it? The hardest part is mostly over. Now it's just adding support for
> more objects and polishing it, hardening it and probably adding features
> based on requests (like security).
> 
> * SP:
> recreate procedure demo (
>   in_int integer,
>   in_s varchar(20),
>   in_long bigint,
>   in_short smallint,
>   in_char char(20)
> ) 
> returns (
>   out_int integer,
>   out_s varchar(20),
>   out_long bigint,
>   out_short smallint,
>   out_char char(20)
> )
> external name 'Example!Example.Procedures.Demo'
> engine dotnet;
> * Code (not sure about the tuples yet):
> public static IEnumerator>
> Demo(int? i, string s, long? @long, short? @short, string @char)
> {
>   yield return Tuple.Create(i, s, @long, @short, @char);
>   yield return Tuple.Create(i + 1, s + nameof(Demo), @long + 1,
>   (short?)(@short + 1), @char);
> }
> 
> -- 
> Mgr. Jiří Činčura
> Independent IT Specialist
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Firebird-net-provider mailing list
> Firebird-net-provider@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] [FB-Tracker] Created: (DNET-669) rare null reference exception in OnRemoteEventCounts

2016-02-23 Thread Alexander Muylaert-Gelein (JIRA)

rare null reference exception in OnRemoteEventCounts


 Key: DNET-669
 URL: http://tracker.firebirdsql.org/browse/DNET-669
 Project: .NET Data provider
  Issue Type: Bug
Affects Versions: 4.10.0.0
Reporter: Alexander Muylaert-Gelein
Assignee: Jiri Cincura


Hi Jiri@Jira

On rare occasions we found a null reference exception log inside our exception 
system.  During the FbRemoveEnvet.OnRemoveEventCounts it fails somewhere.

I've checked the code and the only place I can see failing is 

if (RemoteEventCounts != null)
{
_synchronizationContext.Send(_ =>
{
RemoteEventCounts(this, args);
}, null);
}

how about rewriting that to
var evt = RemoveEventCounts;
if (evt != null){
  _SynchronizeContext.Send( _ => evt(this, args));
}

I'll try to include the pdb file with the exe to help you out.

thanks

a



-- 
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



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] [FB-Tracker] Created: (DNET-657) Lots of exceptions by transaction destructor

2015-12-22 Thread Alexander Muylaert-Gelein (JIRA)

Lots of exceptions by transaction destructor


 Key: DNET-657
 URL: http://tracker.firebirdsql.org/browse/DNET-657
 Project: .NET Data provider
  Issue Type: Bug
  Components: ADO.NET Provider
Affects Versions: 4.9.0.0
Reporter: Alexander Muylaert-Gelein
Assignee: Jiri Cincura
Priority: Critical


FbTransaction doesn't dispose the internal GDSTransaction anymore.  
If you look at FbTransaction.Commit, you'll notice it calls UpdateTransaction.  
This method just sets the _transaction to null.  The dispose of this internal 
transaction isn't being called.

The disadvantage of this is that I have a lot of unwanted errors being spawned 
inside the gc thread.  If you replace the code in fbtransaction by the 
following, it seems to work fine

private void UpdateTransaction()
{
if (_connection != null && _connection.InnerConnection 
!= null)
{

_connection.InnerConnection.TransactionUpdated();
}

_isUpdated = true;
_connection = null;
if (_transaction != null)
{
_transaction.Dispose();
_transaction = null;
}
}


-- 
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



--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] VS2008 ADO.NET confusion

2015-12-02 Thread Alexander Muylaert-Gelein

I had likewise errors on multiple computers in the past weeks. They all had 
failed windows updates in common. Completely updating windows solved it for me 
on multiple occasions.

Sent from my Windows Phone

From: Jiří Činčura
Sent: ‎2/‎12/‎2015 11:27
To: 
firebird-net-provider@lists.sourceforge.net
Subject: Re: [Firebird-net-provider] VS2008 ADO.NET confusion

On Tue, Dec 1, 2015, at 16:26, slucas wrote:
> ok, that is great, less dlls to deal with.  so whether i put the
> FirebirdSql.Data.FirebirdClient.dll in the \windows directory or in the
> directory right next to the exe, i still get the same error.  it throws
> back:
>
> Error {exe name}
> MissingMethodException
> Could not load type
> 'FirebirdSql.Data.FirebirdClient.FbConnection'
> from assembly
> 'FirebirdSql.Data.FirebirdClient' version 2.5.2.0, culture=neutral,
> PublicKeyToken={long number}
>
> so obviously the exe is calling the FirebirdSql.Data.FirebirdClient.dll
> properly and that dll is throwing back an error.  i think you are
> correct.  i need the same FirebirdSql.Data.FirebirdClient.dll but
> probably for an older version of .NET.  i am thinking for .NET2.0.

Hi, you can try some older versions from
https://sourceforge.net/projects/firebird/files/firebird-net-provider/ .
There were CF versions before.

--
Mgr. Jiří Činčura
Independent IT Specialist

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Parser class/library

2015-10-05 Thread Alexander Muylaert-Gelein

I know we are sponsoring This... But it sounds to me like so much work and so 
little gain. Sure, the current parse thing is slow and buggy, but only a few 
minor bugs and performance gain Will be limited as well. I think looking at 3th 
party parsers isn,'t a bad idea at All.

Sent from my Windows Phone

From: Jiří Činčura
Sent: ‎6/‎10/‎2015 6:38
To: For users and developers of the Firebird .NET 
providers
Subject: Re: [Firebird-net-provider] Parser class/library

On Mon, Oct 5, 2015, at 21:32, Michał Ziemski wrote:
> IMHO you won't be able to handle all the corner cases without full
> grammar
> parser.

Well, the cases we need are not that wide. But it's tedious anyway.

> For example consider a "SET TERM" inside an "EXECUTE BLOCK".
> Lacking the grammar understnding you won't recognize that as an invalid
> term in the execute block and
> you'll simply cut the block in half. So the decision is how far do you

I don't care much about invalid scripts. It fails either way. But I
agree that it's at least confusing for people consuming the library.

> want
> to go.

Personally, not far. :) There's way more interesting pieces.

> Writing a full scale parser for FB SQL in a rather easy but very tedious
> and time-consuming task.
> Having that as a tool would be a great addition to FB ecosystem.
> The parser in FB itself is written in yacc so it's faily transportable.
> Sill you'll have to go rule by rule
> and convert to C#.
> Actually I have tried this myself in F# (it's far far better suited for
> parsers) and am about 50% through.
> I would gladly donate the code if you'd be interested.

I don't think it will hurt.

> If you would preffer the faster approach I would suggest:
>  - a simple lexer by hand that recognizes tokens "SET" "TERM"
> CURRENT_TERM_SYMBOL "--" , NEWLINE OTHER_TOKEN and STRING
>  - a parser that iterates the tokens form lexer, tests for sequences:
> "SET" "TERM" OTHER_TOKEN CURRENT_TERM_SYMBOL - to set new terms
> CURRENT_TERM_SYMBOL - to yield accumulated OTHER_TOKENs and STRINGs
> -  -- to start a comment and skip everything till NEWLINE
> this should be an easy enough state machine to write by hand.

That's what I'm currently doing. Sadly.

--
Mgr. Jiří Činčura
Independent IT Specialist

--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Migrations

2015-10-01 Thread Alexander Muylaert-Gelein

Hi  all
Jiri asked me to kick in because we have two products.  One with one generator 
per column, one with one generator per database.
Pro's of generator per table are
You have the feeling of a sequence. There shouldn't be a gap, you can do "math" 
on it.This is how other db's have it since DBase.
Pro's of one generator per database...  
I have an orm that more or less only works fine if you assign the PK on 
creation of the object. Per instance I can now do a single trip to the db and 
do gen_id(pk, 1000) and create myself a nice pool of unique ids that I can 
design without additional roundtrips to the db.
It really removes all sense from PK's and that is how I think it should be.  
There are huge gaps and that is perfectly explainable.  
All records inside the db have a unique key. 
If you ever need to synchronize two db's... you can start the one on 
1.000.000.000, second on 2.000.000.000, ...  whatever
You don't need to manage 5 billion generators.  
Imho opinion I would never go back to generator per table.  I discover every 
month new goodies that make my choice for 1 generator awesome.  But I do 
think... for the common sense and feeling...  one table, one generator makes 
most sense...  even when it sucks.
Hopes this solves your debate.
Alexander

> From: j...@cincura.net
> To: firebird-net-provider@lists.sourceforge.net
> Date: Thu, 1 Oct 2015 19:24:00 +0200
> Subject: Re: [Firebird-net-provider] Migrations
> 
> On Thu, Oct 1, 2015, at 19:21, Jiří Činčura wrote:
> > But then we're back where we started. Question is whether the global
> > definition for whole migration generator or per column is more
> > understandable and discoverable for developers.
> 
> And I'm not sure we two can find the answer. Wish others jumped in.
> 
> -- 
> Mgr. Jiří Činčura
> Independent IT Specialist
> 
> --
> ___
> Firebird-net-provider mailing list
> Firebird-net-provider@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Compiling error

2015-09-23 Thread Alexander Muylaert-Gelein

Yes...
If you switch to Visual Studio 2015... it is solved.Looks to me that Jiri is 
already on the next level.

From: nftimm...@hotmail.com
To: firebird-net-provider@lists.sourceforge.net
Date: Wed, 23 Sep 2015 10:53:57 -0300
Subject: [Firebird-net-provider] Compiling error

Hello When i download the last release from 4_8 
https://github.com/cincuranet/FirebirdSql.Data.FirebirdClient/releases I’m 
getting the following error attached Seen’s that FbTransactionOption.cs is 
incomplete
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider  
  --
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Multithread insert

2015-09-20 Thread Alexander Muylaert-Gelein

I don't think there is even an issue here.  inside two different transactions, 
you simply cannot update the same record.  Who would win in the end and what 
would be the end result.  I'm pretty sure if you can solve this, the firebird 
team would gladly implement this.
a

> Date: Sun, 20 Sep 2015 14:12:25 +0300
> From: zabulu...@gmail.com
> To: firebird-net-provider@lists.sourceforge.net
> Subject: Re: [Firebird-net-provider] Multithread insert
> 
> I don't think that the issue in the .NET provider. It just forwards
> options to fbembed.dll for transactions it just TPB. And do it right.
> The problem is in the engine, I've retested it with C API and the
> behavior is similar to observed. My case is similar to the described
> here: http://www.firebirdfaq.org/faq109/. With just one difference:
> values field updated to is not depends on each other. I just update
> the same field from several threads. I've crutched this with skipping
> the exception because consistency is not a concern for this field. But
> IMO, there is an issue in the engine.
> 
> On 20 September 2015 at 14:03, LtColRDSChauhan  wrote:
> >> Message: 3
> >> Date: Thu, 17 Sep 2015 19:56:20 +0200
> >> From: Ji?? ?in?ura 
> >> Subject: Re: [Firebird-net-provider] Multithread insert
> >> To: "For users and developers of the Firebird .NET providers"
> >> 
> >> Message-ID:
> >> <1442512580.927417.386542585.69829...@webmail.messagingengine.com>
> >> Content-Type: text/plain; charset="UTF-8"
> >>
> >> On Thu, Sep 17, 2015, at 17:57,  ?? wrote:
> >> > Narrowed the problem. The cause is a multithreaded update of the same
> >> > record field. Transactions, as I said don't dispatch the issue.
> >>
> >> The advice is simple. Don't update same record (not only in .NET;
> >> anywhere, anytool). :D
> >>
> > Transactions issues in .NET Provider  need to be addressed.
> > Multithread/parallel programming and transactions enable correct
> > exploitation of multicore machines.  I understand Firebird 3.0 takes major
> > advances in this area.
> >
> >
> > --
> >
> > ___
> > Firebird-net-provider mailing list
> > Firebird-net-provider@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
> >
> 
> --
> ___
> Firebird-net-provider mailing list
> Firebird-net-provider@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] [FB-Tracker] Created: (DNET-622) Performance optimization for FbCommand.LogCommand

2015-08-12 Thread Alexander Muylaert-Gelein (JIRA)

Performance optimization for FbCommand.LogCommand
-

 Key: DNET-622
 URL: http://tracker.firebirdsql.org/browse/DNET-622
 Project: .NET Data provider
  Issue Type: Improvement
  Components: ADO.NET Provider
Affects Versions: 4.7.0.0
Reporter: Alexander Muylaert-Gelein
Assignee: Jiri Cincura


Hi 

I noticed that the emitting of the trace code is relatively slow.  It takes a 
few percentages (6%) of the total duration of a restore script.   Including 
Localhost traffic to the database.
First I disabled all the listeners inside the app config.  This brought it down 
to 0.7% of the total time needed to rescript the db.
I propose one additional minor tweak to prevent formatting the message at all.  
That brings the required processing time down to 0.088%.



-- 
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



--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] ADO.NET provider 4.7.0.0 and DDEX 3.0.2

2015-07-24 Thread Alexander Muylaert-Gelein

Hi Jiri
Thanks, I'll make sure it is tested this weekend on our servers.Already 
available on nuget, because update-package doesn't work yet?
thanks
a

 From: j...@cincura.net
 To: firebird-net-provider@lists.sourceforge.net; 
 firebird-de...@lists.sourceforge.net; firebird-to...@yahoogroups.com
 Date: Fri, 24 Jul 2015 07:01:39 +
 Subject: [Firebird-net-provider] ADO.NET provider 4.7.0.0 and DDEX 3.0.2
 
 More info:
 * 
 http://blog.cincura.net/233515-ado-net-provider-4-7-0-0-for-firebird-is-ready/
 * http://blog.cincura.net/233514-ddex-provider-3-0-2-for-firebird-released/
 
 The uploads on SF will be done when SF is back up working.
 
 -- 
 Mgr. Jiří Činčura
 Independent IT Specialist
 
 --
 ___
 Firebird-net-provider mailing list
 Firebird-net-provider@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] OutOfMemoryException

2015-06-18 Thread Alexander Muylaert-Gelein

You might already have expected this.  I don't think Jiri is aware of any leaks 
inside the provider, otherwise they would have been resolved.
Can you make a reproducible scenario?
thanks
a

 From: lo...@nucleo.co.za
 To: firebird-net-provider@lists.sourceforge.net
 Date: Thu, 18 Jun 2015 16:34:36 +0200
 Subject: [Firebird-net-provider] OutOfMemoryException

 Hello, I have an application that runs on .NET 4.5.1 against FB 2.5.2. Up to
 now I have been using FirebirdClient 2.0.1. I have just migrated to using
 FirebirdClient 4.6.2 with the view of getting some performance gains.

 When I run my application's automated test suite of around 1500 tests using
 client 2.0.1, the test suite runs through. However, when I run the test
 suite against client 4.6.2, I get OutOfMemoryException at around 80% mark.

 The first question is whether client 4.6.2 will give me performance gains.
 Second question is why would I run out of memory with 4.6.2 and not 2.0.1?

 Thanks
 Louis

 --
 ___
 Firebird-net-provider mailing list
 Firebird-net-provider@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Keep-alive packets

2015-06-18 Thread Alexander Muylaert-Gelein

Yes, I was planning to reply on facebook as well.  
I was a bit surprised, but this could be the reason why
1.  It is random2.  It is on some networks often, on others rarely or never3.  
It is for no reason.
In all honesty, I always try to keep a socket live with actual CHANGING bytes 
every 30 seconds.  We are running tests now, we limit events on 14 per 
fbRemoteEvent and we add one NewGuid.ToString() that we fire every minute with 
a fbBlock if we haven't seen any of those events in the past minute.  The 
results look promising.

 From: j...@cincura.net
 To: firebird-net-provider@lists.sourceforge.net
 Date: Thu, 18 Jun 2015 05:44:50 +
 Subject: [Firebird-net-provider] Keep-alive packets
 
 Hi *,
 
 This is what I read just now:
 RFC 1122, section 4.2.3.6 indicates that acknowledgements for TCP keepalives 
 without data may not be transmitted reliably by routers; this may cause valid 
 connections to be dropped. Furthermore, TCP/IP stacks are not required to 
 support keepalives at all (and many embedded stacks do not), so this solution 
 may not translate to other platforms.
 
 This might explain why still some events (connections) are (sometimes) lost, 
 even though we use keep-alive on that socket. 
 
 -- 
 Mgr. Jiří Činčura
 Independent IT Specialist
 --
 ___
 Firebird-net-provider mailing list
 Firebird-net-provider@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Random crashes in Finalizers

2015-04-08 Thread Alexander Muylaert-Gelein

Hi
No, I have to admit I've abondoned EF long time ago.  Too much magic behind the 
scenes for me.  I couldn't predict the behavior of EF and that was too hard to 
manage.  I also don't use embedded.  I have a lot of pooled connections on cs 
and ss and normal stay open long connections on mostly ss.  For mapping I 
prefer LLBLGEN pro, because it is dumb and thus does what I want and nothing 
extra.  
thanks
a

 Date: Wed, 8 Apr 2015 18:16:36 +0300
 From: zabulu...@gmail.com
 To: firebird-net-provider@lists.sourceforge.net
 Subject: Re: [Firebird-net-provider] Random crashes in Finalizers
 
 We use FbConnection in EF. EF does not always calls Dispose on classes
 provided by the FB Data provider.
 Alexander, what server do you use? For example, we use embedded
 configuration in our production. And code of the Fes* namespace
 doesn't work well in finalizers as we see.
 
 On Wed, Apr 8, 2015 at 6:12 PM, Alexander Muylaert-Gelein
 amuylaert_gel...@hotmail.com wrote:
  Hi
 
  I intensively use firebird and provider... I always use the dispose method
  (using) and I don't depend on the GC for this.  I never had any of the
  exceptions refererred to.
 
  Wouldn't it be better *not* to depend on something horrible as the gc for
  something as important as your db connectivity?  Isn't it better to prevent
  then to cure?
 
  thanks
 
  a
 
 
  Date: Wed, 8 Apr 2015 18:00:26 +0300
  From: zabulu...@gmail.com
  To: firebird-net-provider@lists.sourceforge.net
  Subject: [Firebird-net-provider] Random crashes in Finalizers
 
 
  Hello everyone.
 
  I want to discuss changes in finalizers regarding a couple of crashes
  we experience in our FB using.
 
  Issues in tracker:
  http://tracker.firebirdsql.org/browse/DNET-582
  http://tracker.firebirdsql.org/browse/DNET-597
 
  As for 582 we have discussion in PR that crutches it on GitHub:
  https://github.com/cincuranet/FirebirdSql.Data.FirebirdClient/pull/19
 
  As for 597 try...catch doesn't work, it is a more complicated problem.
 
  My suggestion is to refactor Dispose/Finalizer methods to not use
  managed objects which might be already disposed.
 
  Maybe anyone have another thought?
  JIri, what do you think?
 
 
  --
  BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
  Develop your own process in accordance with the BPMN 2 standard
  Learn Process modeling best practices with Bonita BPM through live
  exercises
  http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
  event?utm_
  source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
  ___
  Firebird-net-provider mailing list
  Firebird-net-provider@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
 
  --
  BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
  Develop your own process in accordance with the BPMN 2 standard
  Learn Process modeling best practices with Bonita BPM through live exercises
  http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
  source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
  ___
  Firebird-net-provider mailing list
  Firebird-net-provider@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
 
 
 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Firebird-net-provider mailing list
 Firebird-net-provider@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Random crashes in Finalizers

2015-04-08 Thread Alexander Muylaert-Gelein

Hi
I intensively use firebird and provider... I always use the dispose method 
(using) and I don't depend on the GC for this.  I never had any of the 
exceptions refererred to.  
Wouldn't it be better *not* to depend on something horrible as the gc for 
something as important as your db connectivity?  Isn't it better to prevent 
then to cure?
thanks
a

 Date: Wed, 8 Apr 2015 18:00:26 +0300
 From: zabulu...@gmail.com
 To: firebird-net-provider@lists.sourceforge.net
 Subject: [Firebird-net-provider] Random crashes in Finalizers
 
 Hello everyone.
 
 I want to discuss changes in finalizers regarding a couple of crashes
 we experience in our FB using.
 
 Issues in tracker:
 http://tracker.firebirdsql.org/browse/DNET-582
 http://tracker.firebirdsql.org/browse/DNET-597
 
 As for 582 we have discussion in PR that crutches it on GitHub:
 https://github.com/cincuranet/FirebirdSql.Data.FirebirdClient/pull/19
 
 As for 597 try...catch doesn't work, it is a more complicated problem.
 
 My suggestion is to refactor Dispose/Finalizer methods to not use
 managed objects which might be already disposed.
 
 Maybe anyone have another thought?
 JIri, what do you think?
 
 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Firebird-net-provider mailing list
 Firebird-net-provider@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Questions with performance metrics doing large inserts into DB

2014-08-09 Thread Alexander Muylaert-Gelein

Hi 
Attached some examples of transactions properly set.
If you can put the reader in readonly  and the writer in WriteNoUndo, you 
gain some speed.  But euh, no magic to expect here.  It might be interesting to 
profile it though and post the results back.
public static class Transaction
 {
 private static FbTransactionOptions s_WriteTransaction = new 
FbTransactionOptions()
 {
 TransactionBehavior = FbTransactionBehavior.Write |
   FbTransactionBehavior.ReadCommitted |
   FbTransactionBehavior.RecVersion |
   FbTransactionBehavior.Wait,
 WaitTimeout = new TimeSpan(0, 0, 0, 10) //seconds
 };
 
 public static FbTransactionOptions WriteTransactions
 {
 get
 {
 return s_WriteTransaction;
 }
 }
 
 private static FbTransactionOptions s_WriteNoUndoTransaction = new 
FbTransactionOptions()
 {
 TransactionBehavior = FbTransactionBehavior.Write |
   FbTransactionBehavior.ReadCommitted |
   FbTransactionBehavior.RecVersion |
   FbTransactionBehavior.Wait |
   FbTransactionBehavior.NoAutoUndo,
 WaitTimeout = new TimeSpan(0, 0, 0, 10) //seconds
 };
 
 public static FbTransactionOptions WriteNoUndoTransactions
 {
 get
 {
 return s_WriteTransaction;
 }
 }
 
 private static FbTransactionOptions s_ReadTransaction = new 
FbTransactionOptions()
 {
 TransactionBehavior = FbTransactionBehavior.Read |
   FbTransactionBehavior.ReadCommitted |
   FbTransactionBehavior.RecVersion |
   FbTransactionBehavior.NoWait
 };
 
 public static FbTransactionOptions ReadTransactions
 {
 get
 {
 return s_ReadTransaction;
 }
 }
 
 
 public static FbTransaction BeginReadTransaction(this FbConnection 
aConnection)
 {
 return aConnection.BeginTransaction(s_ReadTransaction);
 }
 
 public static FbTransaction BeginWriteTransaction(this FbConnection 
aConnection)
 {
 return aConnection.BeginTransaction(s_WriteTransaction);
 }
 
 public static FbTransaction BeginWriteNoUndoTransaction(this FbConnection 
aConnection)
 {
 return aConnection.BeginTransaction(s_WriteTransaction);
 }
 }
I read somewhere that Looping in .NET is somewhat slower than in Delphi, but 
there are things you can do optimize the .NET loops.
Agreed, some tricks might be applied.  But that will bring you down from 18.7 
seconds to 18.69998 seconds.  Optimizing loops is actually not the way to go.  
What you could do is make a small test project.  with a few simple tables.  Add 
your simulations to it and make sure it compiles.  Then, if you have these 
minimal projects building, I would like to receive a copy and I can profile for 
you.
Maybe I can already see what is wrong.  Like Jiri mentioned.  .Net is slower 
then this FIB/FBClient (c++) dll.  But let us assume that is 10% overhead.  So 
4 seconds delphi = 5 seconds .net is fine for me.  18 seconds...  I'm 
interested in speeding things up then  :-)
thanks
a
From: emendez...@nc.rr.com
To: firebird-net-provider@lists.sourceforge.net
Date: Fri, 8 Aug 2014 09:41:03 -0400
Subject: Re: [Firebird-net-provider] Questions with performance metrics doing 
large inserts into DB

Alexander, Thank you for the feedback. Two more things...   1.  Your 
transaction parameters please.  How do you create them, what settings?To be 
honest I’ve never really thought about the transaction settings other than the 
default. Are there a specific settings I should be using for just reading 
“stale” data?2.  Did you check your source-read logic.  Cound you maybe 
fake data, so we know if it is the insert that is slow.  Maybe the 
materializing of the source record is slow or fetching it?I was doing further 
testing last night and removed the insert logic to see if it was the reading of 
the data that was slowing it down. with the removal of the Insert Logic and 
just reading and looping for 5000 iterations, it still slower than Delphi’s 
results. For the read Logic I was using Dapper dot net and retrieving the 
results un-buffered (one row at a time). I then eliminated Dapper and it still 
was slower than Delphi. I then tried an OleDB Provider and that was a little 
faster than the .Net provider, but still slower than Delphi.  In retrospect I 
might have jumped the gun in blaming the Write performance of the .Net 
Provider. I think I need to try to optimize the read logic, then move on to the 
Write Logic. I read somewhere that Looping in .NET is somewhat slower than in 
Delphi, but there are things you can do optimize the .NET loops.  Thank you, 
Edward Mendez From: Alexander Muylaert-Gelein

Re: [Firebird-net-provider] Questions with performance metrics doing large inserts into DB

2014-08-08 Thread Alexander Muylaert-Gelein

I personally really like the one from red-gate
but the visual studio profiler is also good.
a

 From: emendez...@nc.rr.com
 To: firebird-net-provider@lists.sourceforge.net
 Date: Fri, 8 Aug 2014 09:51:52 -0400
 Subject: Re: [Firebird-net-provider] Questions with   performance metrics 
 doing large inserts into DB
 
 Jiri,
 
 I am not familiar with Profiling. Is there one that you can recommend? 
 
 Thank you,
 
 Edward Mendez
 
 Also, are there any tests that I can 
  -Original Message-
  From: Jiří Činčura [mailto:disk...@cincura.net]
  Sent: Friday, August 8, 2014 1:59 AM
  To: For users and developers of the Firebird .NET providers
  Subject: Re: [Firebird-net-provider] Questions with performance metrics
  doing large inserts into DB
  
  Hi,
  
  Any chance to do profiling? I would expect .NET be slightly slower that 
  .NET,
  but this is x-times slower. That's weird. But finding the bottleneck might 
  be
  helpful.
  
  
  --
  Mgr. Jiří Činčura
  Independent IT Specialist
  
  
  --
  Want fast and easy access to all the code in your enterprise? Index and
  search up to 200,000 lines of code with a free copy of Black Duck
  Code Sight - the same software that powers the world's largest code
  search on Ohloh, the Black Duck Open Hub! Try it now.
  http://p.sf.net/sfu/bds
  ___
  Firebird-net-provider mailing list
  Firebird-net-provider@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
 
 
 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Firebird-net-provider mailing list
 Firebird-net-provider@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
  --
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Questions with performance metrics doing large inserts into DB

2014-08-07 Thread Alexander Muylaert-Gelein

Hi Edward
I'm also coming from a delphi background (using FIB) and we have ported/are 
already porting for 5 years our applications to .net.  I have noticed indeed 
that Delphi/fib is faster then .net provider.  But never in the magnitude of 
500%.  It looked acceptable slower.
Your write code seems to be correct and pretty optimal.  Usually people 
recreate a command each time.  I've also done some profiling in the past and 
I've noticed that keeping a reference to the parameter doesn't help much.  A 
slightly slower method, but way less code is to clear the parameters and 
recreate them.   Once again, It is slightly slower, neglectible, but in your 
scenario 170 lines of code less.  
using (command = new command){  var par = command.Parameters   while (! Eof){   
par.Clear();   par.Add(Id);   par.Add(Value);   ...   }}
On the other hand Firebird is an open source database and also the .net 
provider.  Jiri (the guy supporting this) is getting a few bucks per month to 
support this.  We, as a company, sometimes sponsor these things by testing, 
benchmarking or lazy picking up the bill.  Since you have a testing environment 
up and running, you might walk the extra mile and help everybody by profiling a 
bit deeper?  This would benefit you, me and everybody.  
Two more things...  
1.  Your transaction parameters please.  How do you create them, what 
settings?2.  Did you check your source-read logic.  Cound you maybe fake 
data, so we know if it is the insert that is slow.  Maybe the materializing 
of the source record is slow or fetching it?
Looking forward for tackling this thing.
thanks
a





From: emendez...@nc.rr.com
To: firebird-net-provider@lists.sourceforge.net
Date: Thu, 7 Aug 2014 18:14:43 -0400
Subject: Re: [Firebird-net-provider] Questions with performance metrics doing 
large inserts into DB

Hello All, I have to develop an application that will move old/stale data 
from certain tables to another FB DB. We already have an existing application 
that did something similar to this, but his application is written using Delphi 
5 and we are a .NET shop and wanted to develop newer applications using .NET 
technologies so we can reuse our developer resources. Little by Little we have 
been migrating off from Delphi5 to .NET. In our shop we are running various 
instances of FB on 2.14 Classic on CentOS 5.6. Our Database is larger than 
250GB.  In past .NET projects I have used Dapper dot Net and thought that this 
might fit the requirements.  We developed a working prototype of what we wanted 
I had our testers run the application to see what they thought. To my dismay, 
they informed me that the performance was terrible. In some cases we need to 
archive millions of rows to the other Database. And it seemed using dapper was 
not giving us acceptable results. The users said that using the old Delphi 
applications was quicker when archiving data ( that Delphi application has 
functionality that also archives different data to other Databases). I wanted 
to have a baseline test so we can compare apples to apples.  I trimmed down the 
prototype to eliminate Dapper dot net and use straight ADO.NET  for the Inserts 
using the latest Firebird.NET provider on .NET 4.5.1. In the 
application once the data was retrieved I read it one row at a time, because 
trying to read in over a million rows into memory would cause Out of Memory 
issues. A sample of the code I am using is shown below. As I looped over the 
results, I reported on every 1000 rows and calculated elapsed times every 5000 
rows. Running this application from various computers in our infrastructure to 
various target DBs the best performance I got was 19 seconds for 5000 rows.  I 
then put on my Delphi Hat On and created a small app that did similar to what 
the .NET app is doing and the Delphi app’s performance blew away the .NET 
performance with a consistent 5000 rows @ 4 seconds. This is Delphi5! From the 
year 1999. I also have to add that I am using the FIBPlus data components from 
devrace.  Below is an edited version of my .NET code. query = @Select *** Here 
is my Select Query from the Source DB *** ; // This is using dapper.net to 
retrieve the rows I need.var en = db_source.QueryTABLE_A_DTO(query, new { 
ARCHIVE_SET_ID = m_archiveSetId, ARCHIVE_DATA_TYPE = _tableName }, 
srcTransaction, buffered: false);int totalUpdated = 0;JobStartTime = 
DateTime.Now;try  {using (FbConnection db_target = 
((FbConnection)GetConnection(targetDB))){  
FbTransaction transaction = db_target.BeginTransaction();  
m_isInTransaction = true;   using (FbCommand command = new 
FbCommand(_updateSQL, db_target, transaction))  {   
   command.Parameters.Add(TABLE_A_ID, 
FbDbType.Integer);  // 
There are 86 fields in the result set so i do this 85 more

Re: [Firebird-net-provider] .NET 4 support

Re: [Firebird-net-provider] Firing event when event count is 0

Re: [Firebird-net-provider] Stored procedures etc. in .NET

[Firebird-net-provider] [FB-Tracker] Created: (DNET-669) rare null reference exception in OnRemoteEventCounts

[Firebird-net-provider] [FB-Tracker] Created: (DNET-657) Lots of exceptions by transaction destructor

Re: [Firebird-net-provider] VS2008 ADO.NET confusion

Re: [Firebird-net-provider] Parser class/library

Re: [Firebird-net-provider] Migrations

Re: [Firebird-net-provider] Compiling error

Re: [Firebird-net-provider] Multithread insert

[Firebird-net-provider] [FB-Tracker] Created: (DNET-622) Performance optimization for FbCommand.LogCommand

Re: [Firebird-net-provider] ADO.NET provider 4.7.0.0 and DDEX 3.0.2

Re: [Firebird-net-provider] OutOfMemoryException

Re: [Firebird-net-provider] Keep-alive packets

Re: [Firebird-net-provider] Random crashes in Finalizers

Re: [Firebird-net-provider] Random crashes in Finalizers

Re: [Firebird-net-provider] Questions with performance metrics doing large inserts into DB

Re: [Firebird-net-provider] Questions with performance metrics doing large inserts into DB

Re: [Firebird-net-provider] Questions with performance metrics doing large inserts into DB

19 matches

Site Navigation

Mail list logo

Footer information