I understand there is a way to alter big.mark for an entire theme but I wonder if there is a way to remove it for a single variable? I am displaying summary statistics for year of birth and ideally it would not have a comma (e.g., "1988" is better than "1,988").
Many thanks,
Doron
Related
I'm already struggling for days to use dates from excel in a proper way in anylogic..
I've created a database in where the date is formulated as integers in different columns since otherwise excel is messing up the dates (for example year=2021 , month=12 day=5 hour=6 minute=44 second=0 stands for 2021/12/5 6:44:00)
Now I know this can be converted to a date by the function toDate(year, month, day, hour, minutes seconds). But how can I use this integers to create agent with specific parameters from the database in a source and add to a custom population?
The most simple way is to add a column where the function toDate(......) is added in the database but I do not know how to do this (see picture if it is unclear). Or are there other solutions?
One way: use Dynamic Events.
Create one and in the action code, write mySource.inject(1)
In Main, on startup, load all dbase rows and create a DE for each row, below assuming it is only with an hour-column:
(Use the database query wizard to adjust your query).
In your source object, set it to "call of inject() function"
This will work, but it is quite cumbersome, as you can see. Much easier if you get your Excel right and just import the date column clean and well so you can use the Source option "arrival table in database" directly. I know you need regular arrivals, so maybe code that up in Excel to give you these on specific dates...
I am using Microsoft Access 2016. I am trying to find out how many years exist from the current year until a future year. I have a column that is end_date. I am trying to create a calculated field that is essentially YEAR(end_date) - YEAR(current_year). I tried to use YEAR(DATE()) but DATE() is not allowed to be used in a calculated field apparently.
Is there no way to do a calculation like this?
Nope. Calculated fields are cached and static, so are NEVER allowed to contain ANY information that will change over time, due to system settings, or anything else that is not directly entered in that row.
However, you should not be using calculated fields anyway. See http://allenbrowne.com/casu-14.html, among many posts advocating for not using calculated fields.
Instead, use queries to do calculations. That way, you won't have any trouble using the current date, and won't have to deal with the possible errors and portability issues calculated fields come with.
I changed my thinking to calculate this in a form. It does not seem good practice to have a field in a DB that changes everyday.
In a form, you can use this expression as controlsource for a textbox:
=DateDiff("yyyy",Date(),[EndDate])
However, that return the difference in calendar years. To find the count of full years, use a function like AgeSimple and this expression:
=AgeSimple([EndDate])
I'm trying to get a formula that will break down the amount of times a user enters a contest each day.
I'm pretty new to this whole thing, basically putting it together using google to figure out the code I need to use/modify. Explaining why something works would be greatly appreciated so I can use it elsewhere!
Here's a dummy of the form I'm banging my head against.
I would like the form to be reusable, so on the Sorted form I have a date key that automatically fills out the week when you choose the first day. Because of this, I would like each formula to refer to this date key, instead of manually typing the google equivalent of 'February 1st, 2015' into the formula.
I've tried to use the SUMIFS formula, and I've run in to a few errors.
Apparently both pages have to be the same amount of rows, otherwise I get an 'Array arguments to SUMIFS are of different size'. I didn't want my 'sorted' sheet to be 1761 rows long, since all of the duplicate names will have been condensed and I wanted it prettier. Nuts to that! Guess I can hide the rows? Is there any other solution?
It looks like this works:
=SUMIFS(Entered!E3:E1000, Sorted!E3:E1000, Sorted!$E3, Entered!A3:A1000, date(Sorted!$C7))
Where entered!E: is the number of entries, sortedE: is the list of usernames, and E3 is the specific one I'm looking for. Then EnteredA3 is the list of dates and time, and Sorted!C7 is the specific date I'm looking for. I don't get any results!
If I click on my C7 and sorted!A, the little calender pops up, which means they are dates (I think?). One includes the hours:minutes:seconds and the other doesn't, which I think is my problem. I would like to have sorted!C7 be the entire day, and filter out all of those entries.
This is taking information entered via a google form which I won't have control of, so I can't really change the H:M:S additions to the date column.
Thinking ahead to day 2 and onwards, will the same formula work when sorted!C10 is C$7$+1? Is it not a date anymore?
I would also like to add up the amount of daily entries, in sorted!S7 and below. I've tried wrapping both the column of dates and the date from my day key in the date() thing, but it doesn't seem to work either.
=SUMIF(date(Entered!A3:A),date(Sorted!C7),Entered!E3:E)
It gives me a '1', and I have no idea where that comes from.
I haven't been able to find much about the google SUMIFS function, mostly how to replicate it from before it was a thing.
And for even MORE complexity:
I was wondering if it is possible to have UNIQUE find the IDs in entered!C, and return all the associated usernames. That pesky angelo changed their username to 'pants' midway through the contest, and I'd like to be able to see both names and add up both 'angelo' and 'pants' entries in the same line in my formulas.
I feel like I'll need a few hidden columns that have the UNIQUE ID number and the associated usernames that I pull into my Sorted!Username column, but I don't know how to search the IDs to find the different usernames.
I tried to google that, but I have no idea what I'm googling.
Whewph! That is a lot of questions, thanks for any help!
Too long for my taste, but you might try:
=sumifs(Entered!E:E,Entered!A:A,">="&$C$7,Entered!A:A,"<"&$C$7+1,Entered!B:B,$E3)
in Sorted!F3 and copied down to suit.
Oh my goodness, you are a hero!
My final code wound up being:
=IF(ISBLANK(Sorted!$E3)=TRUE, "", sumifs('Entered'!$E:$E,'Entered'!$A:$A,">="&$C$7,'Entered'!$A:$A,"<"&$C$7+1,'Entered'!$B:$B,$E3))
I changed the start and end points by making $C$7 into $C$7+1, and the ending one into +2. (In case anyone else is looking at this answer.)
I'm super pleased that it worked!
Using this I managed to add up each of the daily entries, just by adding up the columns they were in.
I gave up on the UNIQUE idea, if someone changes their username during the contest, then they can add up the two rows themselves.
Thanks again! I'd upvote you, but I can't yet.
We have a database that stores the bank account of our clients like this:
|client|c01|c02|c03|c04|d01|d02|d03|d04|
|a |3€ |5€ |4€ |0€ |-2€|-1€|-4€| 0€|
This is the structure of the database when we are in the month 3. In month 4 would be:
|client|c01|c02|c03|c04|c05|d01|d02|d03|d04|d05|
|a |3€ |5€ |4€ |2€ |0€ |-2€|-1€|-4€|-2€| 0€|
take attention on the c05 and d05.
The database auto-updates adds those columns.
Because of this changing in the columns I can't get the sum of c01, c02, c03, c04, d01, d02, d03, d04 easily. I was thinking of making a function that checks the current month and makes a loop in order to select and sum those columns without errors.
If you have a better idea to do it, you are welcome.
But the main question is how to make a function that is able to sum a variable number of columns?
thanks
There's something about adding a column every month that bugs me. I know it can be a valid OLAP strategy as selective de-normalization, but it just feels wierd here. Usually with these kinds of things, the entire width is specified, if for no other reason than to avoid ALTER TABLE statements. I don't know enough about what you're storing there to give a recommendation otherwise, but I guess I just prefer fully normalized structures.
Having done similar endeavours, your best bet will be to use dynamic sql. You can place that inside your stored procedure, PREPAREing and EXECUTEing as normal.
OK I have a Master Table of shipments, and a separate Charges table. There are millions of records in each, and it's come into Filemaker from a legacy system, so all the fields are defined as Text even though they may be Date, Number, etc.
There's a date field in the charges table. I want to create a number field to represent just the year. I can use the Middle function to parse the field and get just the year in a Calculation field. But wouldn't it be faster to have the year as a literal number field, especially since I'm going to be filtering and sorting? So how do I turn this calculation into its value? I've tried just changing the Calculation field to Number, but it just renders blanks.
There's something wrong with your calculation, it should not turn blank just because field type is different. I.e.:
Middle("10-12-2010", 7, 4)
should suffice, provided the calc result is set to Number. You may also wrap it into GetAsNumber(...), but, really, there's no difference as long as field type is right.
If you have FM Advanced, try to set up your calc in the Data Viewer (Tools -> Data Viewer) rather than in Define Fields, this would be faster and, once you like the result, you can transfer it into a field or make a replace. But, from the searching/sorting standpoint there's no difference between a (stored) calculation and a regular field, so replacing is pointless and, actually, more dangerous, as there's no way to undo a wrong replace.
Here's what i was looking for, from
http://help.filemaker.com/app/answers/detail/a_id/3366/~/converting-unstored-calculation-fields-to-store-data
:
Basically, instead of using a
Calculation field, you create am EMPTY
Number, date or text field and use
Replace Field Contents from the Records menu, and put
your calculation (or reference, or
both) there.
Not dissing FileMaker at all, but millions of records means FileMaker is probably the wrong choice here. Your system will be slow, slow, slow. FileMaker is great for workgroups and there is no way to develop a database app faster. But one thing FileMaker is not good at is handling huge numbers of records.
BTW, Mikhail Edoshin is exactly right.