I am having a problem with ElevateDB that looks like the lenght of the name of the foreign key is too big and is getting truncated and this is causing to duplicate with another name.

It seems to be always trunc around 30 chars, is there such limitation ?

I am using it thru TMS Aurelius and wanted to confirm where the limitation is...

Thank  you

On 6/27/2014 8:37 AM, Eduardo wrote:
> I am having a problem with ElevateDB that looks like the lenght of the name of the foreign key is too big and is getting truncated and this is causing to duplicate with another name.
> It seems to be always trunc around 30 chars, is there such limitation ?
> I am using it thru TMS Aurelius and wanted to confirm where the limitation is...
>

Are you referring to the field name or actual content ?

EDB identifiers are 40 characters as per link below so that's what you
might be seeing.

Other system capacities are listed here :
http://www.elevatesoft.com/manual?action=topics&id=edb2sql&section=appendix_system_cap

Raul

yes exactly that... the 40 chars limit is what is right now causing me problem. I was giving more descriptive names for the fields, and Aurelius attach to the name some kind of "namespace" ie, it appends a prefix to make sure to not have duplicates, so this prefix + descriptive name is getting too long....

I hoped the era of 8.3 was long ago... but ...

Thank you for the link

Raul wrote:

On 6/27/2014 8:37 AM, Eduardo wrote:
> I am having a problem with ElevateDB that looks like the lenght of the name of the foreign key is too big and is getting truncated and this is causing to duplicate with another name.
> It seems to be always trunc around 30 chars, is there such limitation ?
> I am using it thru TMS Aurelius and wanted to confirm where the limitation is...
>

Are you referring to the field name or actual content ?

EDB identifiers are 40 characters as per link below so that's what you
might be seeing.

Other system capacities are listed here :
http://www.elevatesoft.com/manual?action=topics&id=edb2sql§ion=appendix_system_cap

Raul

Is there any possibility of increasing this limitation?

I have found this is the problem that I am having.

This code below is part of a SQL generated by TMS Aurelius to be used on ElevateDB:

CONSTRAINT "PK_MOVIMENTACAOCAIXAPDVITEMS" PRIMARY KEY ("ID"),
CONSTRAINT "FK_MOVIMENTACAOCAIXAPDVITEMS_CONTATOFUNC" FOREIGN KEY ("IDFUNCSUPERVISOR") REFERENCES "CONTATOFUNCIONARIO" ("IDCONTATO")
  ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FK_MOVIMENTACAOCAIXAPDVITEMS_DOCMOV_IDDO" FOREIGN KEY ("IDDOCMOV") REFERENCES "DOCMOV" ("ID")
  ON UPDATE NO ACTION ON DELETE NO ACTION

as you can see the last CONSTRAINT is long and actually got truncated.

I was using not using abbreviations for table names, since in the past that cause confusion when to project is aging.

I am already starting to rename some cases like this one, but I dont like the idea of taking this in account this during programming, I believe there is not need of such huge limitation.

<Eduardo> wrote:
> Is there any possibility of increasing this limitation?
>
> I have found this is the problem that I am having.
>
> This code below is part of a SQL generated by TMS Aurelius to be used on ElevateDB:
>
> CONSTRAINT "PK_MOVIMENTACAOCAIXAPDVITEMS" PRIMARY KEY ("ID"),
> CONSTRAINT "FK_MOVIMENTACAOCAIXAPDVITEMS_CONTATOFUNC" FOREIGN KEY
> ("IDFUNCSUPERVISOR") REFERENCES "CONTATOFUNCIONARIO" ("IDCONTATO")
>    ON UPDATE NO ACTION ON DELETE NO ACTION,
> CONSTRAINT "FK_MOVIMENTACAOCAIXAPDVITEMS_DOCMOV_IDDO" FOREIGN KEY
> ("IDDOCMOV") REFERENCES "DOCMOV" ("ID")
>    ON UPDATE NO ACTION ON DELETE NO ACTION
>
> as you can see the last CONSTRAINT is long and actually got truncated.
>
> I was using not using abbreviations for table names, since in the past
> that cause confusion when to project is aging.
>
> I am already starting to rename some cases like this one, but I dont like
> the idea of taking this in account this during programming, I believe
> there is not need of such huge limitation.

Raise a support case. Both with Elevate and TMS. TMS may face this on other
systems and might be able to constrain more easily.

--
Matthew Jones

Matthew Jones wrote:

> Raise a support case. Both with Elevate and TMS. TMS may face this on
> other systems and might be able to constrain more easily.

To expand on that from a full size keyboard, I suspect that Elevate
cannot make an instant change, but knowing that it can be an issue
might make affordances in the future. TMS on the other hand are much
more likely to see this on many systems, and are probably in the better
place to fix immediately, even if it is a matter of putting it through
some sort of naming system to ensure unique names within a certain
length constraint.

--

Matthew Jones

Matthew

>> Raise a support case. Both with Elevate and TMS. TMS may face this on
>> other systems and might be able to constrain more easily.
>
>To expand on that from a full size keyboard, I suspect that Elevate
>cannot make an instant change, but knowing that it can be an issue
>might make affordances in the future. TMS on the other hand are much
>more likely to see this on many systems, and are probably in the better
>place to fix immediately, even if it is a matter of putting it through
>some sort of naming system to ensure unique names within a certain
>length constraint.

I'm pretty sure this has been raised with Tim on previous occasions and I think he raised it from 30 to 40 but that's as far as it goes.

My personal opinion is that the onus is on TMS. They know / should know the limitations of the systems they're dealing with.

Roy Lambert

Roy Lambert wrote:

> My personal opinion is that the onus is on TMS. They know / should
> know the limitations of the systems they're dealing with.

Indeed - there will always be limits, and they are the ones who can fix
it. EDB seems great, and if the schema was all really table based then
it could be adjusted by changing the column length, but really that
becomes ridiculous at some point. Having columns of 256 characters
starts to just be a waste of time. Better in an automated system to
have a prefix that is going to be quickly unique. Something like:
A123_field_details_truncat
A124_other_field_details_t
etc

--

Matthew Jones

Roy,

I have complained that with TMS, they should pay attention to that when creating the names.

HOWEVER, looking closely I see that the 40 limit is way low.

In a big erp software (that I am doing with Elevate) you generally use namespaces to identify things and separate modules etc, etc

And if you want to use descritive names like 'ItemComposition' and 'ItemCompositionItems' for the details I have already take half of the limit !!!!!

255 as limit is just fine and understandable, since there is many reasons to not go far 255 due corss platforms  etc etc

TMS will only say that the limit was reached and cant do anything. I want to go beyond the limit

"Matthew Jones" wrote:

Roy Lambert wrote:

> My personal opinion is that the onus is on TMS. They know / should
> know the limitations of the systems they're dealing with.

Indeed - there will always be limits, and they are the ones who can fix
it. EDB seems great, and if the schema was all really table based then
it could be adjusted by changing the column length, but really that
becomes ridiculous at some point. Having columns of 256 characters
starts to just be a waste of time. Better in an automated system to
have a prefix that is going to be quickly unique. Something like:
A123_field_details_truncat
A124_other_field_details_t
etc


Matthews

That is the same argumentation used on MSDOS era

Now computers, specially servers where I will be running ElevateDB have many gigabytes of memory and terabytes of HardDrive.

There is no way to automate that, since ORMs, specially Aurelius is based on tagging the class like this: (the class will be persisted automatically by the ORM, there is no control over the database directly)

 [Entity]
 [Table('ITEMPRODUTO')]
 [PrimaryJoinColumn('ID')]
 TEntityItemProduto = class(TEntityItem)
 private
   [Association([TAssociationProp.Lazy], [])]
   [JoinColumn('IDFABRICANTEROTULO', [])]
   FFabricanteRotulo: Proxy<TEntityRotuloFabricante>;


Not easy to "automate" the way you said. This needs to be manual and "A123" means nothing to me. We lost all the reason of documenting ! An one more thing, SQL Sentences are already very lengthy, what the reason to limit that much?

There is a difference when using full OOP and when you go the old Delphi way direct to the table. We used to do some hacking to overcome limitations in the old way and the code turn quickly a patchwork.

In the example above it will generate a Indentifier "pk_IDFABRICANTEROTULO_ITEMPRODUTO" that is big for this limitation, but you can see clearly that is descriptive and not exagerated !!!!

See I can live with this limitation, I have already adjusted the code for that. But because I like so much ElevateSoft products (I am a long term user of DBISAM) I posted this complain/request.

I am done with this, Just want to let my willing that this limit is too low. What I could see from my code is that 100 chars is more than enough. Please report to development and if it could eventually be added I will be happy, if cant I will be happy either.

Thank You !
--


Matthew Jones