I use AppMaker with Google Cloud SQL and needed to change a String field to Date (StartDate).
A page on the AppMaker guides said 'To change the field type, delete and recreate the field.', as I deleted the field I was prompted to choose between 'Delete data' or 'Keep data', I chose keep data as I had input some already.
I then went on to recreate the field with the same name (StartDate) but as Date now and I get "Duplicate column name 'StartDate'".
This is an expected behavior. If you have a field with string data type and then you want to convert that to a date data type, app maker won't do that for you. These are two different types of data. Since you've chosen to keep the data, the field was deleted from app maker's interface; however, the data is still available in google cloud sql. If you really want to keep the data, you'll have to create a new field with a different name, but if you really need the field with the same name and a different data type, you'll need to do the following:
In app maker, go to the app settings:
2.Then go the database and click on check:
You will be presented with the three options:
In summary, appmaker is not able to create the field with the same name and different data type because the field name already exists in the sql backend. The only thing you can do is to completely delete that field and get rid of the data, or restore the field and continue using strings. I hope this helps!
Related
I am looking for a way to change the names of the items in a custom field I created in studio, without changing their display labels.
I used the field editor (still in studio) to change the associations between names and labels, but despite my modifications, I am still getting the former names (those that were defined before my modifications) when I'm using the API.
How can I make the new names be effective?
Thank you for your help.
When you change the keys in a dropdown list (you called them 'names'), it will change the language file in SugarCRM, but will not change the existing values in your database. So a query to existing records that used the old keys will still return those old key values.
You will need to perform UPDATE queries in your database similar to:
UPDATE contacts_cstm SET mydropdownvalue_c='NewValue' where mydropdownvalue_c = 'OldValue';
I am trying to work around a limitation that Filemaker 12 seems to have. In a value list that links to an ODBC attached SQL Server database, it doesn't display every piece of data. If there are 2 people with the same last name for example, it only displays the first person with that last name in the list. This is verified by the following in the Filemaker documentation (which I found after a lot of digging)
If the value list is defined to display information from two fields, items will not be duplicated for the field on which the value list is sorted. For example, if the value list displays information from the Company field and the Name field, and if the values are sorted by the Company field, only one person from each company will appear in the value list.
Portals on the other hand will find all the related data, I just don't understand how do something with the data once I get it in the portal. I essentially thus wish to use a portal AS my drop-down value list, and then to use it as I would have a value list (which is then to act as the key to do the rest of the lookups on the page to fill out the invoice.
The major issue here (other than this maddening choice Filemaker seems to make) is that the external file I am pulling the data from is an ODBC mounted SQL Server file, so I can't do something easy like a calculated field which would give me last name & " " & first which would make almost every person unique. Filemaker won't let me do that because it says I can't do that with a field that is not indexed. Any help would be greatly appreciated!
Assuming that we're starting with table MyTable and we're trying to get a ID from the People table for the selected person, which we'll call ID so that we can put it into MyTable::PersonID
Start by creating a new Table Occurrence of your People table and call it PeopleWhoCanBeSelected. If you want every person in the People table you can connect it to MyTable with the X relationship. If you want to show just a subset of the people you can build a different relationship.
Now, on a layout displaying records from MyTable you will make a portal showing records from the PeopleWhoCanBeSelected table.
In the portal put a button. When that button is pressed use the Set Field script step:
Set Field MyTable::PersonID to:
PeopleWhoCanBeSelected::ID
That should do it. You can make the button an invisible overlay on the entire portal record if you like, so that the user clicks on "the name" instead of "the button next to the name".
Now, if you want to pull additional data through to the MyTable record, you'll need to create a second Table Occurrence, called People with the relationship MyTable::PersonID = People::ID. Then you can get information on the specifically chosen person through that relationship.
In CRM, when I'm, trying to set up a work flow, I get to choose the timeout to be related to a certain entity's creation time. There are three fields to relate to.
Record Created On
Created On
Modified On
While the last one is very obvious, I can't see any logical difference between the two others.
The difference is that Created On (createdon) is filled out automatcally by the server when you actually create the record, while Record Created On (overriddencreatedon) will usually be null (unless the record was imported into CRM and you chose to explicitly override the record creation date to match when it was created in another system).
You should use the first and skip the latter, as it's not supported (as far I've got it right when I talked to a MVP about it). Why it show, she had no idea and neither do I. Maybe #JamesWood has a shot. He usually does. (sucking-up in progress)
I've never used the latter and I believe you'll keep your hair off-grey and on-head if you stick to the same approach.
From the SDK:
The createdon attribute specifies the date and time that the record was created. To import data in the createdon attribute, map the source column that contains this data to the overriddencreatedon attribute.
During import, the record’s createdon attribute is updated with the value that was mapped to the overriddencreatedon attribute and the overriddencreatedon attribute is set to the date and time that the data was imported.
If no source value is mapped to the overriddencreatedon attribute, the createdon attribute is set to the date and time that the data was imported and the overriddencreatedon attribute is not set to any value.
Link to BlogSpot
Link to Social MSDN
I'm trying to copy some field values to a duplicate database. One record at a time. This is used for history and so I can delete some records in the original database to keep it fast.
I don't want to manually save the values in a variable because there are hundreds of fields. So I want to go to the first field, save the field name and value and then go over to the other database and save the data. Then run a 'Go to Next Field' and loop through all the fields.
This works perfectly, but here is the problem: When a field is a calculation you cannot tab into it and therefore 'Go to Next Field' doesn't work. It skips it.
I though of doing a 'Go to Object' but then I need to name all the objects and I can't find a script to name objects.
Can anyone out there think of a solution?
Thanks!
This is one of those problems where I always found it easier to do an export/import.
Export all the data you want from the one database, and then import it into the other database. All you need to do is:
Manually specify which fields you want to copy
Map the data from the export to the right fields in the new database/table
You can even write a script to do these things for you.
There are several ways to achieve this.
To make a "history file", I have found there are several cases out there, so lets take a look.
CASE ONE
Single file I just want to "keep" a very large file with historical data, because I need to erease all data in my Main file.
In this case, you should create a "clone" table (in the same file ore in other file, is the same). Then change any calculation field to the type of the calculation result (number, text, date, an so on...). Remove any "auto entered value or calculation from any field, like auto number, auto creation date, etc..). You will have a "Plain Table" with no calculations or auto entered data.
Then add a field to control duplicate data. If you have lets say an invoice number (unique) for each record, you can do this to achieve this task. But if you do not have a unique field that identifies the record as unique, then you have to create one...
To create such a field, I recommed to add a new field on the clone table and set as an aunto entered calculation and make a field combination that is unique... somthing like this: invoiceNumber & "-" & lineNumber & "-" " & date.
On the clone table make shure that validation is set up for "always", and no empty values allowed and that this value is unique.
Once you setup the clone table... then you can import your records, making sure that the auto enty option is on. Yo can do it as many times as you like, new records will be added and no duplicates.
If you want, can make a Script to do the move to historical table all the current records before deleting them.
NOTE:
This technique works fine when the data you try to keep do not have changes over time. This means, once the record is created is has no changes.
CASE TWO
A historical table must be created but some fields are updated.
In the beginnig I thougth a historical data, never changes. In some cases I found this is not the case, like the case I want to track historical invoices but at the same time, keep track if they are paid or not...
In this case you may use the same technique above, but instead of importing data... you must update data based on the "unique" fields that identifiy the record.
Hope this technique helps
FileMaker's FieldNames() function, along with GetField() can give you a list of field names and then their values
I am trying to store metadata (basically a unique id) along with each cell of a table in a Word document. Currently, for the add-in I'm developing, I am querying the database, and building a table inside the Word document using the data that is retrieved.
I want to be able to save any of the user's edits to the document, and persist it back to the database. My initial thought was to store a unique id along with each cell in the table so that I would be able to tell which records to update. I would also like to store some sort of "isChanged" flag within each cell so that I could tell which cells were changed. I found that I could add the needed information into the "ID" property of the cell - however, that information was not retained if the user saved the document, closed it, and re-opened it. I then tried storing the data by adding a data to the "Fields" collection - but that did not work and threw a runtime error. Here is the code that I tried:
object t1 = Word.WdFieldType.wdFieldEmpty;
object val = "myValue: " + counter;
object preserveFormatting = true;
tbl.Cell(i, j).Range.Fields.Add(tbl.Cell(i, j).Range, ref t1, ref val, ref preserveFormatting);
This compiles fine, but throws this runtime error "This command is not available".
So, is this possible at all? Or am I headed in the wrong direction?
Thanks in advance.
Wound up using "ContentControls" to store the information I needed. I used the "Title" field to store the unique id, and the "tag" field to track whether the field had been changed or not. See this link for more info: http://blogs.technet.com/gray_knowlton/archive/2010/01/15/associating-data-with-content-controls.aspx
Since a "Word 2007 Document" is XML, you can add a namespace to the document then adore the elements with attributes from your namespace. Word should ignore your namespace when loading and saving. Moreover, you can add new elments to store any information (metadata) needed.
With that said, I have not used this technique with Word, but I have done it successfully using Excel 2003.
First thing to try, is create a bare "Word 2007 Document". In your case, add a simple two by two table. Open it with a text or XML editor and add your namespace, and adore an attribute and add an element. Open with Word make a change then save it. Open with editor and make sure your namespace attribute and element have not been changed.