how you people deal with this NETMAKE crap ?
Avoid using TEXT, they are not working like a big VARCHAR.
You cannot give them default value.
They cannot be part of an index.
It’s very slow to sort them.
They are store outside of the table, internal pointer are used to access them.
You need more memory to work with them.
They are much slower to process.
So if possible use VARCHAR(xxx).
Finally as far as I know VARCHAR are process correctly by NetMake
All this doesn’t change the fact that NetMake often take forever to fix simple bugs
I don’t have issues with text, as long as you use them for tinymce like stuff. I don’t like using varchar, as they are limited in size on some databases, i.e. 4K on Oracle, and that is way too short. The way the data is stored also differs per database. I agree on most other parts though.
I use TEXT() field types for very long time and never had issues (inside the database). I use them mostly to store notes, descriptions and alike. Perhaps some got confused it with the one line string CHAR() or VARCHAR(). When I used other than SC tools in the past, these fields were called MEMO fields (which I think is very adequate name). In SC these are simply TEXT fiels with multiple lines (very poor terminology).
I do not have to sort or index these fields, because they are always stored in the table with some Primary Key , which is usually INT() type. Yor searching ? Yes it might be slow,… I agree.
The problem thought is that when I import the table into SC DICTIONARY, then it is applied to the Form, the field size (the screen size) is set to 32 some thousand characters, by default.
When I manually change and correct the size (ie. to 80 characters), from that moment everything works fine.
THE BIG PROBLEM comes when I run a DICTIONARY update. When I accidentaly check the field size (to update) it again gets the field size assigned to 32 thousand characters. Such field on the form is about 100 screens long. When the FORM adopts its size (as it is set to Automatic width), the form width becomes also 32000 characters wide and obviously the toolbar buttons disappear, because they are beyond the screen frame.
Now. Can I can go and correct that field manually and assign it again to 80 characters ?
Yes I can, but what would I do if I have 200-300 Forms screwed like that ? Doin this manually would take 2 days. If I resotre the backup I would loose at least one day of work.
I reported this several times, but this still hasn’t been fixed. I am simply curious if somebody has some solution or work around for cases like this ?
Not sure why you want to use sc_dictionary in the first place… I have never needed it. And I have 600+ apps in a single project. From what you’re describing, it looks like it overwrites previous manual changes, and since it doesn’t retain manually set values, you are calling it a bug.
But honestly, isn’t this just how the Data Dictionary is designed to work? It’s meant to standardize field settings across applications, not preserve manual tweaks. If you are looking for an automation feature to keep custom field sizes while updating, that’s a different request altogether.
I mean, really…who cares? Just avoid using the Data Dictionary if it messes up your forms. Manually setting field sizes in each form is a one-time fix and prevents all this frustration.
Once I had to change something across all apps…just took me an hour:)
hahaha…
this is interesting how several people look at the same thing and will have completely different opinions, view and feelings, isn’t it ?
Hey Ken - it is your choice not to use it. I do, and I did use it 30 years ago with other tools (similar), so I am used to it and I think it is a great help when we making lots of changes to the database. If one is past the design process and only maintaining dB, with the small changes, then it is not needed anymore.
I am in the first stage.
When updateing MEMO type field it is a common sense to make that field visible on the screen, instead of extending to 30000+ characters. Yes I call it BUG, because it destroyed this field over 200 times in all my Forms. Stating like: “do not use it” is not very helpful, because we all have that choice and we all know that. This is like stating - if your right mirrir in your car is shaking (poor design), then do not use it. If so, then why design it and installing it in first place (?).
Thanks for the comment.
If you have run into this issue 200 times, why keep repeating the same process? Are you expecting a different outcome each time?
If your database design is still evolving, why stress over the application layer already? I don’t quite follow the logic. If my car had a faulty side window, I’d fix it first or find a workaround before taking it out on the road …I wouldn’t risk an accident, especially at 80 to 100 mph on US highways! You know the issue, why risk crashing your car …that also 200 times 
You are nostalgic about past tools and expect the same behavior to continue in other tools. Just my two cents, but when it comes to PHP-based tools, manual control tends to be far more reliable in my experience.
Have a good one!
In the forms you created where there is this “TEXT” type field, does it always come by default with a value of more than 32 thousand characters, or is it when the data dictionary is synchronized?
In the tests we performed, when we created the application, the default value was “50” in the “Number of characters” option.
When we added the table to the data dictionary and then went to the “Edit” option, there are options where the value is more than 32,000, but this is related to the size of the field in the database and in the form itself. The value was not changed in the field interface in the form after the dictionary and applications were synchronized.
Let us know more details about this specific point when creating the application and the settings in the data dictionary so that we can help you.
Best regards!
Hola.
¿Has probado a cambiar las opciones de configuración de visualización del campo? Los pixeles de altura y anchura del objeto.
It gets the width of 32000+ characters when the DICTIONARY is synced and when the dictionary is created from scratch. there are also some dictionary errors popping out and nobody in NETMAKE cares to fix it , despite I keep reporting this again and again…
Here is whet happens:
Agree, I use TEXT() type fields for 30 years, no issues of any kind in a databases (at least in a few which I ususally use, which is MySQL, MSSQL, Postgress, Oracle). Never had a need to index text() fields, but agree that broad search could be slow.
ken - I agree, manual control is always better, but it depends on the skills, time and benefits.
We are building new project and despite the database was carefully designed, it still requires changes and adjustments. That is why Dictionary is helpful to get all the dB updates into the project (but only it it works as expected). Yes - I am nostalgic, because I have used Dictionary concept for many years and always liked the concept.
@aklass, I understand that Scriptcase brings the size of the database field and sets it as current and maximum. Why should they change this behavior and for the specific case of yours, change it to 80 for example (which is the correct number for you or for me could be another), if it suits another user that is the one you really have.
I think that after 5 years they are not going to make a change because you do not want to take the time to change it. I do not understand what do you expect from SC.
Have a good day!