How do I filter the source list based on property value defined in the rule if clause?
for e.g, I bound the two properties with the data source list,
1st Property "Word" Bound with English Word/Arabic Word/Spanish Word.
2nd Property "Fee" Bound with English Word Fee/ Arabic Word Fee/ Spanish Word Fee
Now If the word is equal to English Word then filter the fee property to English Word Fee only.
I guess in Code Effects rule editor it would be as simple as this:
If Word is English then set Fee to English Fee
Else if Word is Spanish then set Fee to Spanish Fee
Else set Fee to Arabic Fee
Related
I am looking to send an email from netsuite using the "Recipients from Results"
I already have a saved search that emails based on field "salesrep", however I want to send a 2nd report to "TAMS" (Territory adoption managers) but only if the TAM is not the same as the sales rep. I am not sure if I will need a workflow to do the comparison or if I need to just add a formula.
Any suggestions ??
None
How about a separate saved search that includes all of your original criteria and additional criteria that would leverage a formula field to say sales rep not equal to TAMS and then email the tams from results?
Formula definitely! DECODE({salesrep},<Yours TAMS field ID>,'Ignore','Email')
I have an access 2010 table with order line detail which includes a field with the price and a separate field for the currency type. That currency type field currently only supports "USD" or "EUR". When the record is shown on a form, I'd like to have the price field format automatically use either Currency or Euro (in design view this can be set manually via property sheet) based on the currency type field. How is that done?
Thank You.
Format will do that, either set as property of a textbox ("Currency") or by an expression:
=Format(123.45, "Currency")
I am using tonumber function but its adding default formatting and i don't want that mainly thousand separator.
Also, for currency, I don't want currency symbol.
As I am using these fields in formula field, I cannot set properties, right?
To remove the thousand separator, I generally do something like
Replace(ToText(YourField),',','')
To remove currency symbols do the same
Replace(ToText(YourField),'£','')
I have two datasets: Dataset1 (primary) and Dataset2. My report dataset is Dataset1.
I want to access Gross premium Amount from Dataset2 and put it in the report. The report is working just fine if the parameter for "market name" is a single value parameter.
When I set the parameter properties to "Allow Multiple Values", my report is displaying wrong Totals for "Production" Field. The problem is because the lookupset function is based on Currency_Type.
What I should do is search for each Market Name and for each currency type, then search for the appropriate Gross Premium in second dataset and return the value.
Dataset1:
Market Name Currency Type Receivable
Dataset2:
Company Name2 Currency Type1 Gross Premium Amount
The results should be like this:
Market Name Currency Type Receivable Gross Premium Amount
I used this code if to search for one value:
=code.SumLookup(LookupSet(Fields!Currency_Type.Value, Fields!Currency_Type1.Value,Fields!Gross_Premium_Amount.Value, "DataSet2"))
What should I do if I want the lookupset based on Market Name and Currency Type combined?
Can you join the datasets in your query? That would be a lot easier, if it's possible. Otherwise you need to have some way to break apart your multi-value parameter, such as a including it as an element in your first dataset. (Maybe even a cross join if appropriate.)
But to directly answer your question
What should I do if I want the lookupset based on Market Name and Currency Type combined?
[Note that this doesn't have much to do with how to lookup a multi-value parameter.]
I have solved this problem by creating a key from the two pieces of information in my queries themselves, such as with string concatenation, but you can also do the same in your LookupSet function:
=LookupSet(Fields!Currency_Type.Value +"-" + Fields!MarketName.Value, Fields!Currency_Type1.Value + "-" + Fields!Market_Name.Value, Fields!Gross_Premium_Amount.Value, "DataSet2"))
This will only work if MarketName is a value in your first dataset.
What is the correct column type for holding ZipCode values in PostgreSQL database?
I strongly disagree with the advice presented here.
The accepted answer accepts things that aren't digits.
The question is about Zip Codes, not postal codes.
If we assume the post is wrong and means international postal codes, there are characters that appear in international postal codes that don't appear in that list, and many international - and also the US domestic - postal codes can be over ten characters
If we actually answer the question they asked, about zip codes, then there should be no accomodation for anything but digits (and arguably the hyphen)
US zip codes can be up to 11 digits long (13 characters counting the two dashes) - there is a zip, a zip+4, and a zip+6 (which programmers would call zip+4+2) notation; the last is used by skyscrapers, universities, et cetera
US zip codes are always non-negative integers, and therefore should not be stored as text data, which is subject to non-canon representation problems (ask anyone who's done a system about that time they found out that their zip 00203 didn't match the zip 203 that they accidentally got when constantly unnecessarily parsing string representations)
If you pretend you're actually tracking international post codes, the short character sequence limited text fields here don't even begin to do the job. The word "China" comes to mind.
My opinon:
Decide whether you're actually handling US postal codes or international
If you're handling US postal codes, track them as unsigned integers, and left-pad them with zeros when text representing them. (Think unix timestamps and local TZ representations if you need to understand why this will be simpler in the long run.)
If you're handling international post codes, store them in an unbounded unicode string, tie them to the country they represent, and validate country by country with check constraints. This problem is far more difficult than it sounds up front. International addresses are some of the least standardized things on Earth. Wait'll you find out how Japanese house numbers work, or why the British postal 6-code has the gaps it has.
It is something like xxxxx-xxxx, so varchar(10) is recommended.
If you want to check the syntax of the values in the database, you could create a domain type for zip codes.
CREATE DOMAIN zipcode varchar(10)
CONSTRAINT valid_zipcode
CHECK (VALUE ~ '[A-Z0-9-]+'); -- or a better regular expression
You could have a look at this site, which proposes this regex:
(^\d{5}(-\d{4})?$)|(^[ABCEGHJKLMNPRSTVXY]{1}\d{1}[A-Z]{1} *\d{1}[A-Z]{1}\d{1}$)
But you should check it works for the PostgreSQL regex syntax.
it depends on what kind of zip you want. if you're sure you will only need to store the standard 5 digit then use an int will be the most space saving.
however if you need to do the 5+4 extended then a 10 digit character field is best. I personally suggest that as it does make it easier in the future if you end up needing to store international postal codes 10 digits covers just about every possible postal code format i've come across.