firebird-net-provider — All about development of the MS .Net provider

Re: [Firebird-net-provider] Migrations

[Геннадий З. <zab...@gm...>]

> 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.
If question only about this, then my opinion that it must be
fine-grained at a column level. But there should be a possibility to
set an implementation for context wide.
It will cover the case where you use mixed scheme: all tables have one
generator, except several that have per table generators. You specify
context-wide implementation per database generator, and in
ModelBuilder you specify generators for these exceptional tables.

On 1 October 2015 at 22:26, Daniel Rail <da...@ac...> wrote:
> Hi,
>
> At October 1, 2015, 2:21 PM, Jiří Činčura wrote:
>
>> On Thu, Oct 1, 2015, at 19:00, Геннадий Забула wrote:
>>> In ModelBuilder you can specify any object as data annotation. In this
>>> case user can provide implementation of the interface.
>
>> 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.
>
> My preference would be at the column level.  Since that would be more
> discoverable for me, because it is close to where it is used.
>
> --
> Best regards,
>  Daniel Rail
>  Senior Software Developer
>  ACCRA Solutions Inc. (www.accra.ca)
>  ACCRA Med Software Inc. (www.filopto.com)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] [FB-Tracker] Created: (DNET-636) FbParameterCollection's Clear method can't set parameter's attribute Parent to null

[ranfu (JIRA) <tr...@fi...>]

FbParameterCollection's Clear method can't set parameter's attribute Parent to null
-----------------------------------------------------------------------------------

                 Key: DNET-636
                 URL: http://tracker.firebirdsql.org/browse/DNET-636
             Project: .NET Data provider
          Issue Type: Bug
          Components: ADO.NET Provider
    Affects Versions: 4.8.1.0
         Environment: any version
            Reporter: ranfu
            Assignee: Jiri Cincura


when we call SQLParameterCollection's Clear method, it will set all parameter's attribute Parent to null,then we can reuse the parameter to add it to another Colletion,but FbParameterCollection's Clear method don'nt clear it

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

        

Re: [Firebird-net-provider] Migrations

[Daniel R. <da...@ac...>]

Hi,

At October 1, 2015, 2:21 PM, Jiří Činčura wrote:

> On Thu, Oct 1, 2015, at 19:00, Геннадий Забула wrote:
>> In ModelBuilder you can specify any object as data annotation. In this
>> case user can provide implementation of the interface.

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

My preference would be at the column level.  Since that would be more
discoverable for me, because it is close to where it is used.

-- 
Best regards,
 Daniel Rail
 Senior Software Developer
 ACCRA Solutions Inc. (www.accra.ca)
 ACCRA Med Software Inc. (www.filopto.com)

Re: [Firebird-net-provider] Migrations

[Alexander Muylaert-G. <amu...@ho...>]

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: ji...@ci...
> To: fir...@li...
> 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
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
 		 	   		  

Re: [Firebird-net-provider] Migrations

[Jiří Č. <ji...@ci...>]

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

Re: [Firebird-net-provider] Migrations

[Jiří Č. <ji...@ci...>]

On Thu, Oct 1, 2015, at 19:00, Геннадий Забула wrote:
> In ModelBuilder you can specify any object as data annotation. In this
> case user can provide implementation of the interface.

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.
-- 
Mgr. Jiří Činčura
Independent IT Specialist

Re: [Firebird-net-provider] Migrations

[Геннадий З. <zab...@gm...>]

> That's why
the interface with some default implementation is so convenient.
In ModelBuilder you can specify any object as data annotation. In this
case user can provide implementation of the interface.

On 1 October 2015 at 19:01, Jiří Činčura <ji...@ci...> wrote:
> On Thu, Oct 1, 2015, at 13:38, Геннадий Забула wrote:
>> I'm talking about "generator creation", it should be hidden in the
>> provider. Though names yes, user should be allowed to pick a naming
>> scheme he wants.
>> In case "one generator for all tables" user specifies one generator
>> name for all tables and provider should check if it exists - nothing
>> to do, if not it creates new. After that it binds the generator name
>> to before insert trigger.
>
> Well that's just part of story. You also need to name the trigger. You
> need to have the body. Some people use like `Id is null` clauses. Some
> also include 0 or -1 (for integers) etc. Not sure how to code this using
> annotations (without implementing all possible combinations). That's why
> the interface with some default implementation is so convenient.
>
>> > Well, the default initializers are using different path.
>> Yep, I'm aware about this. First I've patched one code path. After
>> merge the migration feature I needed to patch another code path, and
>> resulting database had differences.
>
> I'd like to eventually re-use parts of migrations code to have (almost)
> same result.
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Migrations

[Jiří Č. <ji...@ci...>]

On Thu, Oct 1, 2015, at 13:38, Геннадий Забула wrote:
> I'm talking about "generator creation", it should be hidden in the
> provider. Though names yes, user should be allowed to pick a naming
> scheme he wants.
> In case "one generator for all tables" user specifies one generator
> name for all tables and provider should check if it exists - nothing
> to do, if not it creates new. After that it binds the generator name
> to before insert trigger.

Well that's just part of story. You also need to name the trigger. You
need to have the body. Some people use like `Id is null` clauses. Some
also include 0 or -1 (for integers) etc. Not sure how to code this using
annotations (without implementing all possible combinations). That's why
the interface with some default implementation is so convenient.
 
> > Well, the default initializers are using different path.
> Yep, I'm aware about this. First I've patched one code path. After
> merge the migration feature I needed to patch another code path, and
> resulting database had differences.

I'd like to eventually re-use parts of migrations code to have (almost)
same result.

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

Re: [Firebird-net-provider] Debug Error for GdsTransaction.cs Re: Firebird-net-provider Digest, Vol 114, Issue 2

[Jiří Č. <ji...@ci...>]

On Thu, Oct 1, 2015, at 14:12, LtColRDSChauhan wrote:
> With FirebirdSql.Data.FirebirdClient.4.8.1.1, SharpDevelop Debug now runs
> without reporting the error.  Thanks a lot for such a quick response.

We should pinpoint what's causing to go wrong in SharpDevelop. This
version will eventually become next version.

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

Re: [Firebird-net-provider] Inserting strings problem

[Геннадий З. <zab...@gm...>]

Hm, looks like it works. Added .HasMaxLength(256) to all fields and it
goes success ahead.
Before I tried only for one field and it doesn't work.
Thx for fast response.


On 1 October 2015 at 13:56, Jiří Činčura <ji...@ci...> wrote:
> You should specify, at least, the length. Else it's the default and
> that's "unlimited" hence the blob.
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
> On Thu, Oct 1, 2015, at 12:54, Геннадий Забула wrote:
>> Entity:
>>     public sealed class Table
>>     {
>>         public Table()
>>         {
>>             this.Entities1 = new List<Entities1>();
>>         }
>>
>>         public int Id { get; set; }
>>         public string Field1{ get; set; }
>>         public string Field2{get; set; }
>>         public string Field3 { get; set; }
>>         public string Field4 { get; set; }
>>         public string Field5 {get; set; }
>>
>>         public Entities3 Entities3 { get; set; }
>>         public ICollection<Entities1> Entities1{ get; set; }
>>         public ICollection<Entities2> Entities2{ get; set; }
>>     }
>>
>> On 1 October 2015 at 13:53, Геннадий Забула <zab...@gm...> wrote:
>> > We map the entities through EntityTypeConfiguration class:
>> >
>> > Src table mapping:
>> >             this.HasKey(t => t.Id);
>> >
>> >             // Properties
>> >             // Table & Column Mappings
>> >             this.ToTable("TABLE2");
>> >             this.Property(t => t.Id).HasColumnName("ID");
>> >             this.Property(x => x.Field1).HasColumnName("FIELD1");
>> >             this.Property(x => x.Field2).HasColumnName("FIELD2");
>> >             this.Property(x => x.Field3).HasColumnName("FIELD3");
>> >             this.Property(x => x.Field4).HasColumnName("FIELD4");
>> >             this.Property(x => x.Field5).HasColumnName("FIELD5");
>> >
>> > Dst table mapping inherits from above:
>> >
>> > :base()
>> > {
>> >             Property(x =>
>> > x.Id).HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None);
>> > }
>> >
>> > On 1 October 2015 at 13:38, Jiří Činčura <ji...@ci...> wrote:
>> >> How does the entity and mapping looks like?
>> >>
>> >> --
>> >> Mgr. Jiří Činčura
>> >> Independent IT Specialist
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Firebird-net-provider mailing list
>> >> Fir...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Firebird-net-provider mailing list
>> Fir...@li...
>> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] Debug Error for GdsTransaction.cs Re: Firebird-net-provider Digest, Vol 114, Issue 2

[LtColRDSChauhan <rds...@gm...>]

>
>    5. Re: Debug Error for GdsTransaction.cs of ADO.NET provider
>       4.8.1.0 (Ji?? ?in?ura)
>
> Message: 5
> Date: Thu, 01 Oct 2015 12:53:15 +0200
> From: Ji?? ?in?ura <ji...@ci...>
> Subject: Re: [Firebird-net-provider] Debug Error for GdsTransaction.cs
>         of ADO.NET provider 4.8.1.0
> To: "For users and developers of the Firebird .NET providers"
>         <fir...@li...>
> Message-ID:
>         <144...@we...>
> Content-Type: text/plain; charset="UTF-8"
>
> Looks like I uploaded build created from wrong branch. I reuploaded the
> binaries. Please have a look.
>
> --
> Mgr. Ji?? ?in?ura
> Independent IT Specialist
>
_____________________________

With FirebirdSql.Data.FirebirdClient.4.8.1.1, SharpDevelop Debug now runs
without reporting the error.  Thanks a lot for such a quick response.
Regards,

Rajiv

Re: [Firebird-net-provider] Migrations

[Геннадий З. <zab...@gm...>]

> No. You talked about generator/identity columns. Possibly replacing the
interface.
I think I've lose the point in this.

> That's definitely not. You can have one generator for all tables (and
it's even better).
For "Even better" I have doubts. Especially for multithreaded inserts
to different tables case.

> That's definitely not.
I'm talking about "generator creation", it should be hidden in the
provider. Though names yes, user should be allowed to pick a naming
scheme he wants.
In case "one generator for all tables" user specifies one generator
name for all tables and provider should check if it exists - nothing
to do, if not it creates new. After that it binds the generator name
to before insert trigger.

> Well, the default initializers are using different path.
Yep, I'm aware about this. First I've patched one code path. After
merge the migration feature I needed to patch another code path, and
resulting database had differences.

On 1 October 2015 at 14:13, Jiří Činčura <ji...@ci...> wrote:
> On Thu, Oct 1, 2015, at 11:45, Геннадий Забула wrote:
>> >Do you think the annotations will be better?
>> Better than what? Your concern was about different naming schemes, I
>> suggested how it can be resolved via column annotations and custom
>> name providers. I don't know other options for this.
>
> No. You talked about generator/identity columns. Possibly replacing the
> interface.
>
>> >How is the generator creation (if it does not exists) going to be handled? Or are we going to leave that to manual change of Up method in migration?
>> IMO generator creation is an implementation detail that user shouldn't
>> bother about. Generator creation is a part of a table creation.
>
> That's definitely not. You can have one generator for all tables (and
> it's even better).
>
>> >Do you have some more info for this.
>> I'm sure that there were issues about identity columns. The current
>> implementation CreateDatabaseIfExists doesn't create generators in any
>> case, we patched sources to do that. Also, bool fields don't have
>> CHECK IN (0, 1) annotation and so on.
>> I need time to provide additional info for this.
>
> Well, the default initializers are using different path. These existed
> before migrations. The code is different (and also the feature set). It
> also works with EDMX and CF, while migrations are (currently) CF only.
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Migrations

[Jiří Č. <ji...@ci...>]

On Thu, Oct 1, 2015, at 11:45, Геннадий Забула wrote:
> >Do you think the annotations will be better?
> Better than what? Your concern was about different naming schemes, I
> suggested how it can be resolved via column annotations and custom
> name providers. I don't know other options for this.

No. You talked about generator/identity columns. Possibly replacing the
interface.
 
> >How is the generator creation (if it does not exists) going to be handled? Or are we going to leave that to manual change of Up method in migration?
> IMO generator creation is an implementation detail that user shouldn't
> bother about. Generator creation is a part of a table creation.

That's definitely not. You can have one generator for all tables (and
it's even better).
 
> >Do you have some more info for this.
> I'm sure that there were issues about identity columns. The current
> implementation CreateDatabaseIfExists doesn't create generators in any
> case, we patched sources to do that. Also, bool fields don't have
> CHECK IN (0, 1) annotation and so on.
> I need time to provide additional info for this.

Well, the default initializers are using different path. These existed
before migrations. The code is different (and also the feature set). It
also works with EDMX and CF, while migrations are (currently) CF only.

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

Re: [Firebird-net-provider] Inserting strings problem

[Jiří Č. <ji...@ci...>]

You should specify, at least, the length. Else it's the default and
that's "unlimited" hence the blob.

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

On Thu, Oct 1, 2015, at 12:54, Геннадий Забула wrote:
> Entity:
>     public sealed class Table
>     {
>         public Table()
>         {
>             this.Entities1 = new List<Entities1>();
>         }
> 
>         public int Id { get; set; }
>         public string Field1{ get; set; }
>         public string Field2{get; set; }
>         public string Field3 { get; set; }
>         public string Field4 { get; set; }
>         public string Field5 {get; set; }
> 
>         public Entities3 Entities3 { get; set; }
>         public ICollection<Entities1> Entities1{ get; set; }
>         public ICollection<Entities2> Entities2{ get; set; }
>     }
> 
> On 1 October 2015 at 13:53, Геннадий Забула <zab...@gm...> wrote:
> > We map the entities through EntityTypeConfiguration class:
> >
> > Src table mapping:
> >             this.HasKey(t => t.Id);
> >
> >             // Properties
> >             // Table & Column Mappings
> >             this.ToTable("TABLE2");
> >             this.Property(t => t.Id).HasColumnName("ID");
> >             this.Property(x => x.Field1).HasColumnName("FIELD1");
> >             this.Property(x => x.Field2).HasColumnName("FIELD2");
> >             this.Property(x => x.Field3).HasColumnName("FIELD3");
> >             this.Property(x => x.Field4).HasColumnName("FIELD4");
> >             this.Property(x => x.Field5).HasColumnName("FIELD5");
> >
> > Dst table mapping inherits from above:
> >
> > :base()
> > {
> >             Property(x =>
> > x.Id).HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None);
> > }
> >
> > On 1 October 2015 at 13:38, Jiří Činčura <ji...@ci...> wrote:
> >> How does the entity and mapping looks like?
> >>
> >> --
> >> Mgr. Jiří Činčura
> >> Independent IT Specialist
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Firebird-net-provider mailing list
> >> Fir...@li...
> >> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Inserting strings problem

[Геннадий З. <zab...@gm...>]

Entity:
    public sealed class Table
    {
        public Table()
        {
            this.Entities1 = new List<Entities1>();
        }

        public int Id { get; set; }
        public string Field1{ get; set; }
        public string Field2{get; set; }
        public string Field3 { get; set; }
        public string Field4 { get; set; }
        public string Field5 {get; set; }

        public Entities3 Entities3 { get; set; }
        public ICollection<Entities1> Entities1{ get; set; }
        public ICollection<Entities2> Entities2{ get; set; }
    }

On 1 October 2015 at 13:53, Геннадий Забула <zab...@gm...> wrote:
> We map the entities through EntityTypeConfiguration class:
>
> Src table mapping:
>             this.HasKey(t => t.Id);
>
>             // Properties
>             // Table & Column Mappings
>             this.ToTable("TABLE2");
>             this.Property(t => t.Id).HasColumnName("ID");
>             this.Property(x => x.Field1).HasColumnName("FIELD1");
>             this.Property(x => x.Field2).HasColumnName("FIELD2");
>             this.Property(x => x.Field3).HasColumnName("FIELD3");
>             this.Property(x => x.Field4).HasColumnName("FIELD4");
>             this.Property(x => x.Field5).HasColumnName("FIELD5");
>
> Dst table mapping inherits from above:
>
> :base()
> {
>             Property(x =>
> x.Id).HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None);
> }
>
> On 1 October 2015 at 13:38, Jiří Činčura <ji...@ci...> wrote:
>> How does the entity and mapping looks like?
>>
>> --
>> Mgr. Jiří Činčura
>> Independent IT Specialist
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Firebird-net-provider mailing list
>> Fir...@li...
>> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Debug Error for GdsTransaction.cs of ADO.NET provider 4.8.1.0

[Jiří Č. <ji...@ci...>]

Looks like I uploaded build created from wrong branch. I reuploaded the
binaries. Please have a look.

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

On Thu, Oct 1, 2015, at 11:38, LtColRDSChauhan wrote:
> Hello,
> 
> 1.  After upgrading from ADO.NET provider 4.8.0.0 to ADO.NET provider
> 4.8.1.0, now when I run my application through SharpDevelop Debug I get
> Error message :
> 
> Can't load file GdsTransaction.cs under
> C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10.
> Check the file permission and the existence of that file.
> 
> 2.  Followed by another Error message :
> 
> FirebirdSql.Data.Common.IscException: transaction 1 is no valid
>    at System.Void
> FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.CheckTransactionState()
> in
> C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
> 349
>    at System.Void
> FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.Rollback() in
> C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
> 203
>    at System.Void
> FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.Dispose(System.Boolean
> disposing) in
> C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
> 106
>    at System.Void
> FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.Finalize() in
> C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
> 84
> 
> 3.  Reverting back to ADO.NET provider 4.8.0.0 the above errors are not
> reported.
> 
> Regards,
> Rajiv
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Inserting strings problem

[Геннадий З. <zab...@gm...>]

We map the entities through EntityTypeConfiguration class:

Src table mapping:
            this.HasKey(t => t.Id);

            // Properties
            // Table & Column Mappings
            this.ToTable("TABLE2");
            this.Property(t => t.Id).HasColumnName("ID");
            this.Property(x => x.Field1).HasColumnName("FIELD1");
            this.Property(x => x.Field2).HasColumnName("FIELD2");
            this.Property(x => x.Field3).HasColumnName("FIELD3");
            this.Property(x => x.Field4).HasColumnName("FIELD4");
            this.Property(x => x.Field5).HasColumnName("FIELD5");

Dst table mapping inherits from above:

:base()
{
            Property(x =>
x.Id).HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None);
}

On 1 October 2015 at 13:38, Jiří Činčura <ji...@ci...> wrote:
> How does the entity and mapping looks like?
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Inserting strings problem

[Jiří Č. <ji...@ci...>]

How does the entity and mapping looks like?

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

[Firebird-net-provider] Inserting strings problem

[Геннадий З. <zab...@gm...>]

I have next table in two databases:

CREATE TABLE TABLE2(
    ID INTEGER NOT NULL,
    FIELD1 VARCHAR(256),
    FIELD2 VARCHAR(256),
    FIELD3 VARCHAR(512),
    FIELD4 VARCHAR(100),
    FIELD5 VARCHAR(2048))

Using EF I'm trying to copy data from one database to another. I want
to copy full data including Ids, so I disabled Identity Generation for
a destination database.

Problem is the next when EF generates insert it looks like the following:
"INSERT INTO \"TABLE2\"(\"ID\", \"FIELD1\", \"FIELD2\", \"FIELD3\",
\"FIELD4\", \"FIELD5\")\r\nVALUES (@p0, @p1, @p2, @p3, @p4, @p5,
NULL)\r\n"

And I have a problem here, parameters for these fields are treated
like SQL_TEXT and it tries to put UTF8 byte array to VARCHAR fields,
which is wrong. And a query fails on some long strings that in utf8
interpretation longer than 256 for example.

When I turn Identity Generation on, query looks like following:
EXECUTE BLOCK (
 p1 BLOB SUB_TYPE TEXT = @p1, p7 BLOB SUB_TYPE TEXT = @p7, p8 BLOB
SUB_TYPE TEXT = @p8, p9 BLOB SUB_TYPE TEXT = @p9
) RETURNS (
"ID" INT)
AS BEGIN
INSERT INTO "TABLE2"("FIELD2",  "FIELD3", "FIELD4", "FIELD5", "FIELD6")
VALUES (:p1, :p7, :p8, :p9, NULL)
RETURNING "ID" INTO :"ID";
SUSPEND;
END

And it doesn't fail.

Re: [Firebird-net-provider] Migrations

[Геннадий З. <zab...@gm...>]

>Do you think the annotations will be better?
Better than what? Your concern was about different naming schemes, I
suggested how it can be resolved via column annotations and custom
name providers. I don't know other options for this.

>How is the generator creation (if it does not exists) going to be handled? Or are we going to leave that to manual change of Up method in migration?
IMO generator creation is an implementation detail that user shouldn't
bother about. Generator creation is a part of a table creation.

>Do you have some more info for this.
I'm sure that there were issues about identity columns. The current
implementation CreateDatabaseIfExists doesn't create generators in any
case, we patched sources to do that. Also, bool fields don't have
CHECK IN (0, 1) annotation and so on.
I need time to provide additional info for this.

On 30 September 2015 at 22:11, Jiří Činčura <ji...@ci...> wrote:
> OK, so let's talk about Migrations.
>
>> Identity columns.
>
> Do you think the annotations will be better? How is the generator
> creation (if it does not exists) going to be handled? Or are we going to
> leave that to manual change of Up method in migration?
>
>> 4. One more issue I remembered. Dbs created with Initial migration and via CreateDatabaseIfNotExists have different underlying scheme in part of names. I think this should be also fixed.
>
> Do you have some more info for this.
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

[Firebird-net-provider] Debug Error for GdsTransaction.cs of ADO.NET provider 4.8.1.0

[LtColRDSChauhan <rds...@gm...>]

Hello,

1.  After upgrading from ADO.NET provider 4.8.0.0 to ADO.NET provider
4.8.1.0, now when I run my application through SharpDevelop Debug I get
Error message :

Can't load file GdsTransaction.cs under
C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10.
Check the file permission and the existence of that file.

2.  Followed by another Error message :

FirebirdSql.Data.Common.IscException: transaction 1 is no valid
   at System.Void
FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.CheckTransactionState()
in
C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
349
   at System.Void
FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.Rollback() in
C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
203
   at System.Void
FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.Dispose(System.Boolean
disposing) in
C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
106
   at System.Void
FirebirdSql.Data.Client.Managed.Version10.GdsTransaction.Finalize() in
C:\Users\Jiri\Documents\devel\NETProvider\working\NETProvider\src\FirebirdSql.Data.FirebirdClient\Client\Managed\Version10\GdsTransaction.cs:line
84

3.  Reverting back to ADO.NET provider 4.8.0.0 the above errors are not
reported.

Regards,
Rajiv

Re: [Firebird-net-provider] Migrations

[Jiří Č. <ji...@ci...>]

OK, so let's talk about Migrations. 

> Identity columns. 

Do you think the annotations will be better? How is the generator
creation (if it does not exists) going to be handled? Or are we going to
leave that to manual change of Up method in migration?

> 4. One more issue I remembered. Dbs created with Initial migration and via CreateDatabaseIfNotExists have different underlying scheme in part of names. I think this should be also fixed.

Do you have some more info for this.

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

[Firebird-net-provider] ADO.NET provider 4.8.1.0

[Jiří Č. <ji...@ci...>]

More info
http://blog.cincura.net/233531-ado-net-provider-4-8-1-0-for-firebird-is-ready/.

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

Re: [Firebird-net-provider] Parameter check

[Jiří Č. <ji...@ci...>]

OK, glad to be right. It looked too simple to be true. Fixing.

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

Re: [Firebird-net-provider] Parameter check

[Геннадий З. <zab...@gm...>]

It uses this override:
public int IndexOf(FbParameter value)
and checks only if an instance present in the collection, not name. So
Amro El-Fakharany is right, it needs to be rewrote to check by name.
The exception message tells the same: "FbParameterCollection already
contains FbParameter with ParameterName '" + value.ParameterName +
"'."

On 30 September 2015 at 09:29, Amro El-Fakharany <amr...@gm...> wrote:
> Hi Jiri,
> you're not spinning circles.
> Either the check should be value.ParameterName or FbParameter should override the Equals() method accordingly.
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jiří Činčura [mailto:ji...@ci...]
>> Gesendet: Mittwoch, 30. September 2015 08:12
>> An: fir...@li...
>> Betreff: [Firebird-net-provider] Parameter check
>>
>> Hi *,
>>
>> I'm looking at
>> https://github.com/cincuranet/FirebirdSql.Data.FirebirdClient/blob/master/
>> NETProvider/src/FirebirdSql.Data.FirebirdClient/FirebirdClient/FbParameterC
>> ollection.cs#L379
>> and I have a strong feeling the check is not correct. The check should contain
>> `value.ParameterName`, isn't it? Or am I spinning in my own circles...
>>
>> --
>> Mgr. Jiří Činčura
>> Independent IT Specialist
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Firebird-net-provider mailing list
>> Fir...@li...
>> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider