Bug: File Path too short

[skiwi]

In an elements properties, under Related . Files

I tried pasting the delightful URL
http://www.minedu.govt.nz/NZEducation/EducationPolicies/InternationalEducation/ForProvidersOfInternationalEducation/ExportEdIndustryDevFundAndLevy/CollectionOfTheExportEducationLevy/CollectionOfExportEducationLevyFromPrivateTrainingEstablishmentsThatDoNotRecieveGovernmentFunding.aspx
and got an error that the field is too small.

To adequately represent scheme://domain:port/path?query_string#anchor
requires 4.624 characters by my calculations

[Eve]

Unfortunately, it's a restriction of our database schema, which has only been updated for indexes since version 4.0. I wouldn't expect a change any time soon.

[Helmut Ortmann]

Try using an local path to short the path length.

Settings, Local Directories and Paths,...

Helmut

[qwerty]

In an elements properties, under Related . Files

I tried pasting the delightful URL
http://www.minedu.govt.nz/NZEducation/EducationPolicies/InternationalEducation/ForProvidersOfInternationalEducation/ExportEdIndustryDevFundAndLevy/CollectionOfTheExportEducationLevy/CollectionOfExportEducationLevyFromPrivateTrainingEstablishmentsThatDoNotRecieveGovernmentFunding.aspx
and got an error that the field is too small.

To adequately represent scheme://domain:port/path?query_string#anchor
requires [highlight]4.624 [/highlight]characters by my calculations

 

That's a long URL indeed. Looks like you're trying to send mails to your web server ;-)

q.

[Nizam Mohamed]

Did you consider using a tagged value instead.
NB - Type URL does not support more than 255 either, Try using memo

[skiwi]

Suckered into this again.

The point about a URL is that its clickable.

Time the database schema was updated, perhaps.

As for the length


Local path doesn't like URLs (please select relative path first) = kludgy, but ta

[Eve]

I wouldn't expect a change any time soon.

[Graham_Moir]

Have I missed something?  Wouldn't the simplest answer be to use a service like tinyurl.com.  You get a short URL so you can add clickable links and it automatically redirects to the target you want.

[skiwi]

Wouldn't the simplest answer be to use a service like tinyurl.com.

Well yes, you are correct, but that is (another) work around (a bit like adding images to this forum).

Instead Sparx could add a new table to the schema with a decent length, and, say, use, both fields, I'm sure they have the technical capability to make it backwardly compatible, and no doubt there would be other areas that could benefit (e.g. longer tags).

[Eve]

I wasn't here when the last schema update was done. I know only two things. The first is that it was tiny. The second is that it is still haunting the people involved.

That's why I recommend using whatever workaround you need to, because this isn't going to prompt a schema change.

[davidkrethallen]

I also have this issue. I am trying to deep-link to a powerpoint slide in Office 365. As more people move to the web, this will become more annoying.
I get that this won't get fixed ASAP. But how do we get it on the backlog for consideration by the development team. It should at least be logged and the opportunity explored.

[skiwi]

I wouldn't expect a change any time soon.

[qwerty]

The "soon" is superfluous.

q.

[Uffe]

Have I missed something?  Wouldn't the simplest answer be to use a service like tinyurl.com.  You get a short URL so you can add clickable links and it automatically redirects to the target you want.

There are good reasons why you wouldn't want to use such a service. Security and robustness spring immediately to mind. The existence of such services is not something that can be relied upon, and therefore not a reason for this bug to persist.

Taking off in a slightly different direction, what if users just change the schema themselves?

The handling of the t_secuser.UserLogin size issue, which in 15.6.1556 prompted the change Security User login names will now truncate to the database field length rather than a fixed value, to accommodate users extending the field in the Database, suggests that user hacking of the schema is encouraged and the tool will, where necessary, be updated to handle such hacks.

This situation appears to be identical -- an nvarchar that is too short for the purpose. So is this an occasion where hacking is encouraged?

Or will this hack have bad consequences which will not be accomodated in future releases?


/Uffe

[timoc]

Seems like schema changes are allowed, even in point releases - as we just had one for last 15.2 (1557) release (that seems to include the hack above). Possibly this could be fixed in the next point release?

Another 'work around' option that Sparx could consider, is to extend the 'Hyperlink Target Objects' to include something like the javascript: uri type (https://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03'') to generate the target addresses. e.g referencing a script in the library that generates the URL on demand or similar.

This approach could potentially solve other issues, such as situaitons where you want to map to different things depending on the project and environment.  Staging vs Production, or model versions are a few examples.   
Something like:

Code: [Select]

javascript:GeneratePath('Produciton')