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!
