Real length of Salesforce formula-filed - salesforce

I faced with issue that sometimes when I created custom formula-fields on Salesforce objects I couldn't save it, the reason of it was limitation in 5000 characters for such type of field.
The main trouble is that when I copied content of formula to any notepad which can calculate number of characters I saw, that there was less than 5000 characters. After some investigations I found that mentions of other formula-fields and also some methods, like TODAY(), can implicitly increase number of characters. In this way the real length will be more than number of character that you type.
My question - how can I see the real amount of formula-field characters and how to know which parts of formula adds extra-amount?

The code in a Formula Field can exceed the maximum number of characters allowed in two ways:
Directly in the Formula Field's characters (3900). (I think your case)
In the overall size of the Formula after other included Formula
Fields are factored in (5000) bytes.
You can refer this to find workaround Formula Field exceeds maximum number of characters
Hope this Helps !!
Thanks,
Swayam

Related

Excel cumulative count array

tried searching here but found nothing quite fit this query. I'd like to cumulatively count the 'TRUE's in an Excel array. The array is e.g. {TRUE;FALSE;FALSE;TRUE;TRUE;FALSE;TRUE} which I'd like to manipulate to return {1;0;0;2;3;0;4}.
The array is produced by a number of clauses, which I'd rather not call repeatedly to get the answer else the formula will balloon in size !. The numeric result would then be compared with a value e.g. >=3 to return an array of TRUE/FALSEs which are then multiplied by 1 further array, before being converted to dates
All of this is using native Excel not VBA, which I'd like to maintain if possible. I've been trying options for days to get this to work, and would sorely appreciate any advice. Thanks very much for your time, ian taylor.
Using the name Arry for e.g. {TRUE;FALSE;FALSE;TRUE;TRUE;FALSE;TRUE}:
Arry*MMULT(N(ROW(INDEX(A:A,1):INDEX(A:A,ROWS(Arry)))>=COLUMN(INDEX(1:1,1):INDEX(1:1,ROWS(Arry)))),N(Arry))
This may well require committing with CSE, depending upon the construction within which it is employed.
Regards

How to count instances of a string occurring in an array of cells

I have a spreadsheet that tracks where consumers are referred to. To record individual referrals, users select places from a drop down list. This list then populates a cell, with values separated by commas.
On a separate sheet, I need to count the number of referrals for each referral type. So I need to count the # of times DHHS shows up in the array, for example. I've attempted to do this using the following formula:
=SUM(LEN(range))-LEN(SUBSTITUTE(range,"string",""))/LEN("string")
This is working fine for single word strings, but is not working for multiple word strings like "CHIP Water Inquiry". Any ideas why, and what I can do about it?
You need to make two minor corrections, as you are breathtakingly close in your formula. Add a second SUM formula, tally the subtracted length and then house the two subtracted sections within parentheses as you see in the posted formula. As Boris said, Ctrl + Shift + Enter it, as you probably already know. F1 is assumed to hold your "string" that you wish to count.
=(SUM(LEN(range))-SUM(LEN(SUBSTITUTE(range,F1,""))))/LEN(F1)

Storing strings of different sizes in a MATLAB array?

I want to be able to store a series of strings of different sizes such as
userinput=['AJ48 NOT'; 'AH43 MANA'; 'AS33 NEWEF'];
This of course returns an error as the number of columns differs per row. I'm aware that all that is needed for this to work is adequate spaces in the first and second rows. However I need to be able to put this into an array without forcing the user to add these spaces on his/her own. Is there a command that allows me to do this? If possible I'd also like to know why this problem doesn't arise with numbers e.g.
a=[1; 243; 23524];
You cannot do this with standard Matlab arrays. A string is really just a vector of characters in Matlab. And you cannot have a matrix with rows of different lengths.
You can, however, use a cell array:
userinput={'AJ48 NOT'; 'AH43 MANA'; 'AS33 NEWEF'};
disp(userinput{1});
Be aware that there are many situations where cell arrays don't work like normal arrays.
To just answer to your last part of your question; simply because strings may be variable length but numbers (in Matlab) are fixed length. It's one of the main ideas of arrays to let them hold only fixed sizes entities (for example because the need of efficient look up), see more on the topic here.

microsoft access table designing

How do I format a field to be
10 characters or numbers
i.e. 112255353v or 5555551155 (for both these conditions)
The field should contain only 10 characters and it can be numbers or letters or both.
Make the field TEXT(10), and set its input mask to AAAAAAAAAA (10 times A).
But that will only affect data entered manually (through tables, queries or forms), NOT anything updated programmatically or using UPDATE or INSERT queries.
To better enforce your rules, you could set the Validation Rule of the field to:
Like "??????????"
or more precisely:
Like "[0-Z][0-Z][0-Z][0-Z][0-Z][0-Z][0-Z][0-Z][0-Z][0-Z]"
Use Text Data type. Set Field size to 10.
You should to use the text datatype with a max length of 10.
You could then set the minimum length using an input mask of "AAAAAAAAAA" forcing 10 characters. In input masks "A" or "a" represents either a letter or a digit so you are forcing the user to enter 10 characters of this type.
For a good explanation of what else you could achieve using input masks see http://office.microsoft.com/en-us/access-help/control-data-entry-formats-with-input-masks-HA010096452.aspx

Dropping Leading Zeros

I have a form that records a student ID number. Some of those numbers contain a leading zero. When the number gets recorded into the database it drops the leading 0.
The field is set up to only accept numbers. The length of the student ID varies.
I need the field to be recorded and displayed with the leading zero.
If you are always going to have a number of a certain length (say, it will always be 10 characters), then you can just get the length of the number in the database (after it is converted to a string) and then add the appropriate 0's.
However, if this is an arbitrary amount of leading zeros, then you will have to store the content as a string in the database so you can capture the leading zeros.
It sounds like this should be stored as string data. It sounds like the leading zeros are part of the data itself, not just part of it's formatting.
You could reformat the data for display with the leading zeros in it, however I believe you should store the correct form of the ID number, it will lead to less bugs down the road (ex: you forgot to format it in one place but not in another).
There are a few ways of doing this - depending on the answers to my comments in your question:
Store the extra data in the database by converting the datatype from numeric to varchar/string.
Advantages: Very simple in its implementation; You can treat all the values in the same way.
Disadvantage: If you've got very large amounts of data, storage sizes will escalate; indexing and sorting on strings doesn't perform so well.
Use if: Each number may have an arbitrary length (and hence number of zeros).
Don't use if: You're going to be spending a lot of time sorting data, sorting numeric strings is a pain in the ass - look up natural sorting to see some of the pitfalls;
Continue to store the data in the database as numeric but pad the numeric back to a set length (i.e. 10 as I have suggested in my example below):
Advantages: Data will index better, search better, not require such large amounts of storage if you've got large amounts of data.
Disadvantage: Every query or display of data will require every data instance to be padded to the correct length causing a slight performance hit.
Use if: All the output numbers will be the same length (i.e. including zeros they're all [for example] 10 digits); Large amounts of sorting will be necessary.
Add a field to your table to store the original length of the numeric, continue to store the value as numeric (to leverage sorting/indexing performance gains of numeric vs. string) in your new field store the length as it would include the significant zeros:
Advantages: Reduction in required storage space; maximum use of indexing; sorting of numerics is far easier than sorting text numerics; You still get the ability to pad numerics to arbitrary lengths like you have with option 1.
Disadvantages: An extra field is required in your database, so all your queries will have to pull that extra field thus potentially requiring a slight increase in resources at query/display time.
Use if: Storage space/indexing/sorting performance is any sort of concern.
Don't use if: You don't have the luxury of changing the table structure to include the extra value; This will overcomplicate already complex queries.
If I were you and I had access to modify the db structure slightly, I'd go with option 3, sure you need to pull out an extra field to get the length. The slightly increased complexity pays huge dividends in the advantages versus the disadvantages. The performance hit of padding the string back out the correct length will be far superceded by the performance increase of the indexing and storage space required.
I worked with a database with a similar problem. They were storing zip codes as a number. The consequence was that people in New Jersey couldn't use our app.
You're using data that is logically a text string and not a number. It just happens to look like a number, but you really need to treat it as text. Use a text-oriented data type, or at least create a database view that enables you to pull back a properly formatted value for this.
See here: Pad or remove leading zeroes from numbers
declare #recordNumber integer;
set #recordNumber = 93088;
declare #padZeroes integer;
set #padZeroes = 8;
select
right( replicate('0',#padZeroes)
+ convert(varchar,#recordNumber), #padZeroes);
Unless you intend on doing calculations on that ID, its probably best to store them as text/string.
Another option is since the field is an id, i would recommend creating a secondary field for display number (nvarchar) that you can use for reports, etc...
Then in your application when the student id is entered you can insert that into the database as the number, as well as the display number.
An Oracle solution
Store the ID as a number and convert it into a character for display. For instance, to display 42 as a zero-padded, three-character string:
SQL> select to_char(42, '099') from dual;
042
Change the format string to fit your needs.
(I don't know if this is transferable to other SQL flavors, however.)
You could just concatenate '1' to the beginning of the ID when storing it in the database. When retrieving it, treat it as a string and remove the first char.
MySQL Example:
SET #student_id = '123456789';
INSERT INTO student_table (id,name) VALUES(CONCAT('1',#student_id),'John Smith');
...
SELECT SUBSTRING(id,1) FROM student_table;
Mathematically:
Initially I thought too much and did it mathematically by adding an integer to the student ID, depending on its length (like 1,000,000,000 if it's 9 digits), before storing it.
SET #new_student_id = ABS(#student_id) + POW(10, CHAR_LENGTH(#student_id));
INSERT INTO student_table (id,name) VALUES(#new_student_id,'John Smith');

Resources