How do I tell Filemaker what table to paste a value into based on the value? Is there a way to somehow have Filemaker paste a value into a table without hard coding the table name?
Using imported transaction data, I determine which ledger (table) the transaction should be posted to. But I can't seem to get the script to then post it into the right table based on the value.
Screenshot of Script
Thanks for the thoughtful suggestions!
I found a way to do what I was thinking, #AndreasT your suggestion helped.
Case (
Imported_Transactions::Debit_To = "Expenses_All"; "Expenses_All::Description";
Imported_Transactions::Debit_To = "Liability_CrCard_BofA"; Liability_CrCard_BofA::Description;
Imported_Transactions::Debit_To = "Liability_CrCard_CitiBusiness"; Liability_CrCard_CitiBusiness::Description;
)
Using the Case function, I was able to get Filemaker to put the data in the right table. It took some doing, but by putting the tablename::field in quotes, it worked.
Ultimately, though, I found it easier to just use one table and field descriptors to store my data. Simplicity makes it easier to produce reports.
You could use the conditional If script step to determine what table to insert data into based on your input.
Set field by name[ tablename::fieldname ; value ]
Related
In my model I want to loop through the database which contains multiple columns (see example) by an event. The idea behind it is that I want to create dynamic events based on the rows in the database.
But I've no clue how to iterate through a database in anylogic and also was not able to find an example of a loop with a database.
The dummycode of my problem would look something like this:
For order in orderdatabase:
Create order based on (order.name, order.quantity, order.arrivaltime, order.deliverylocation)
Where order in the loop is every row of the database, and the value on which the creation is based based on the different column values of that specific row.
Can somebody give me a simple example of how to create such a loop for this specific problem.
Thanks in advance.
Use the database query wizard:
put your cursor into a code field
this will allow you to open the database wizard
select what you need (in your case, you want the "iterate over returned rows and do something" option
Click ok
adjust the dummy code to make it do what you want
For details and examples, check the example models and the AnyLogic help, explaining all options in detail.
I would love to have a stored procedure which returns a selection which is editable in phpadmin. For example, something as simple as
SELECT * FROM students
written from the console will allow you to edit the records as far as each row is unique (table with a primary key). However, that same statement within a procedure won't allow it!
The point is that I have a selection that I will be using quite often and it's a bit more complex than the one above. If I copy it and paste it on the console, it's fine, but not so when run from a procedure!
I would appreciate any ideas to work around this limitation.
Thank you in advance!
Thanks to those who read my question. I just figured out that a very simple way to solve this issue is to create a table with my output selection. Then, from the console, I can select and edit whatever I need from that temporary table.
Thanks for your time!
I am using TinyMCE to allow users to write in what will eventually be submitted to a database.
TinyMCE includes a button which will insert a "pagebreak" (actually just an HTML comment <!--pagebreak-->).
How can I later pull back everything up to the first occurrence of the pagebreak "tag"? There might be a significant bit of data after that tag which I could discard via php later, but it seems like I shouldn't even bring it back. So I can I SELECT just part of a column if I never know how far in to the data the <!--pagebreak--> will be?
EDIT:
The below answer does work, and will get me where I need to go.. I am just curious as to if there is an equally simple way to handle bringing back the whole column if it is short and thus the pagebreak tag doesn't exist. With the below solution, if no pagebreak is found, an empty string is returned.
If not, then I can easily handle it in the code.
Something like this should get you everything up to the <!--:
SELECT SUBSTRING(my_col FROM 1 FOR POSITION('<!--' IN my_col)-1) AS a_chunk
FROM my_table
Reference for string functions.
Edit:
Just putting OMG Ponies' words into SQL:
SELECT CASE WHEN position('<!--' IN my_col) > 0
THEN SUBSTRING(my_col FROM 1 FOR POSITION('<!--' IN my_col)-1)
ELSE my_col END AS a_chunk
FROM my_table
It sounds like you'll also want a check on the length of the text; whether or not there is a page break. You can use CHARACTER_LENGTH() for that.
why not create another column in your mysql table to store integer value of the position where <!--pagebreak--> is. You'll calculate this value in your script and store this value at same time when you insert the html generated by tinymce.
Then in later retrievals use the value in that column to select the substring from 1 up to the value. This should make your query simpler and maybe improve query performance?
I have a large table which inserts data into the database. The problem is when the user edits the table I have to:
run the query
use lots of lines like value="<cfoutput>getData.firstname#</cfoutput> in the input boxes.
Is there a way to bind the form input boxes to the database via a cfc or cfm file?
Many Thanks,
R
Query objects include the columnList, which is a comma-delimited list of returned columns.
If security and readability aren't an issue, you can always loop over this. However, it basically removes your opportunity to do things like locking certain columns, reduces your ability to do any validation, and means you either just label the form boxes with the column names or you find a way to store labels for each column.
You can then do an insert/update/whatever with them.
I don't recommend this, as it would be nearly impossible to secure, but it might get you where you are going.
If you are using CF 9 you can use the ORM (Object Relation Management) functionality (via CFCs)
as described in this online chapter
https://www.packtpub.com/sites/default/files/0249-chapter-4-ORM-Database-Interaction.pdf
(starting on page 6 of the pdf)
Take a look at <cfgrid>, it will be the easiest if you're editing table and it can fire 1 update per row.
For security against XSS, you should use <input value="#xmlFormat(getData.firstname)#">, minimize # of <cfoutput> tags. XmlFormat() not needed if you use <cfinput>.
If you are looking for an easy way to not have to specify all the column names in the insert query cfinsert will try to map all the form names you submit to the database column names.
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c78.html
This is indeed a very good question. I have no doubt that the answers given so far are helpful. I was faced with the same problem, only my table does not have that many fields though.
Per the docs EntityNew() the syntax shows that you can include the data when instantiating the object:
artistObj = entityNew("Artists",{FirstName="Tom",LastName="Ron"});
instead of having to instantiate and then add the data field by field. In my case all I had to do is:
artistObj = entityNew( "Artists", FORM );
EntitySave( artistObj );
ORMFlush();
NOTE
It does appear from your question that you may be running insert or update queries. When using ORM you do not need to do that. But I may be mistaken.
I have a FileMaker script which calculates a value. I have 1 record from table A from which a relation points to n records of table B. What is the best way to set B::Field to this value for each of these n related records?
Doing Set Field [B::Field; $Value] will only set the value of the first of the n related records. What works however is the following:
Go to Related Record [Show only related records; From table: "B"; Using layout: "B_layout" (B)]
Loop
Set Field [B::Field; $Value]
Go To Record/Request/Page [Next; Exit after last]
End Loop
Go to Layout [original layout]
Is there a better way to accomplish this? I dislike the fact that in order to set some value (model) programmatically (controller), I have to create a layout (view) and switch to it, even though the user is not supposed to notice anything like a changing view.
FileMaker always was primarily an end-user tool, so all its scripts are more like macros that repeat user actions. It nowhere near as flexible as programmer-oriented environments. To go to another layout is, actually, a standard method to manipulate related values. You would have to do this anyway if you, say, want to duplicate a related record or print a report.
So:
Your script is quite good, except that you can use the Replace Field Contents script step. Also add Freeze Window script step in the beginning; it will prevent the screen from updating.
If you have a portal to the related table, you may loop over portal rows.
FileMaker plug-in API can execute SQL and there are some plug-ins that expose this functionality. So if you really want, this is also an option.
I myself would prefer the first variant.
Loop through a Portal of Related Records
Looping through a portal that has the related records and setting the field has a couple of advantages over either Replace or Go To Record, Set Field Loop.
You don't have to leave the layout. The portal can be hidden or place off screen if it isn't already on the layout.
You can do it transactionally. IE you can make sure that either all the records get edited or none of them do. This is important since in a multi-user networked solution, records may not always be editable. Neither replace or looping through the records without a portal is transaction safe.
Here is some info on FileMaker transactions.
You can loop through a portal using Go To Portal Row. Like so:
Go To Portal Row [First]
Loop
Set Field [B::Field; $Value]
Go To Portal Row [Next; Exit after last]
End Loop
It depends on what you're using the value for. If you need to hard wire a certain field, then it doesn't sound like you've got a very normalised data structure. The simplest way would be a calculation in TableB instead of a stored field, or if this is something that is stored, could it be a lookup field instead that is set on record creation?
What is the field in TableB being used for and how?