Looking through my database tables, I'm seeing that the created field is invariably being set as "0000-00-00 00:00:00". The modified field is being auto-populated by sensible dates.
It seems to me very strange that the automagic would get modified right but not created. As far as I can recall I haven't done anything that would unset the created field's value - e.g. specifying it somewhere. Are there any obvious CakePHP "gotchas" I may have fallen foul of that might have messed up my created field in some way?
The only thing I can find in the documentation is that the cakephp only controls this field if it is called "created" and is of type DateTime and the default value is set to NULL. Can you verify that all of this is true in your tables?
Related
In MS Access 2016 I have a table named Master that periodically needs to gets updated with ‘updated’ data from a table named NewData. Each table has the same fields, except Master has one additional field named OTHER_SOURCES (explained further down). They each have an indexed unique id field named EVENT_ID. I’ve built an update query where the tables are joined one-to-one on the EVENT_ID field. In this query I have the fields in Master getting updated to the new values from the same fields in NewData if the TIMESTAMP field value is different. If the TIMESTAMP values haven’t changed, then those records do not get updated. This part is pretty straightforward and works fine.
However, I have end users that may make occasional changes to the values in the SIZE field of Master that need to be preserved and not overwritten with updated values from NEW_DATA. When a user makes a change in SIZE field, he documents the change with information obtained from other sources, which is stored in the extra field I mentioned earlier: OTHER_SOURCES. Here’s what I need to do, and I just can’t figure it out. Whenever a user has made a change to the SIZE field for a record, I need the update query to not override that value in the SIZE field, but still update the values in all the other fields (again, assuming the TIMESTAMP values are different between the two tables). It seems I need to use an IIF statement, but I’m thinking it needs to be done in VBA where I’m a bit of a hack. See screenshots. I greatly appreciate any help you can offer.
enter image description here
enter image description here
You can still proceed with the update, but update it to the same value as its previous value:
SET SIZE= IIF(nz(OTHER_SOURCES,'')<>'', MASTER.Size, NEW_DATA.Size)
This assumes that anything present in the MASTER.OTHER_SOURCES column indicates that the user has changed MASTER.Size. Note that MASTER.Size will never be updated from NEW_DATA.Size until someone (end user) removes MASTER.OTHER_SOURCES.
This is my first database I am building, and am no Access expert, but I do think that I understand the basics.
I have deleted an old field from the back end of a split database, and edited the record sources of the forms that use the table as the record source. I deleted several fields, but one (a number field) is giving me trouble. Whether I open the underlying table or the forms that use the table as a recordsource, an "Enter Paramater Value" Dialogue box appears asking for the value on the form. I have looked at an older version of the database, and the field is not a primary key. I am quite stumped on this one. I have confirmed that the field is deleted from the recordsources and the table, so I'm not sure why it is still behaving like this.
Thanks.
Check Order by and Filter properties of the forms and queries which show such error.
I'm creating a lead record using import function (System->Data Management-> Import), I have creatd a workflow for once the lead record is created, the contact record field 'Salutation' which is a dropdown list must be updated.
When I'm trying to do this, looking for lead doesn't appear to have any value coming on it. Don't know how to set picklist value for updating records using workflow. Please see the screnshot below
That seems odd, you should get all available options when updating a record with a workflow. Is the picklist populated with values? The salutation dropdown is not a standard field in CRM 4.0, it's a freetext field OOB.
Regards
I don't thing pick-list field value can be set dynamically on a record by the field of another entity.
What I did I check multiple cases and update the field manually to achieve this.
i.e. If lead(car1) == 2 update the pick-list value on workflow with your choice. But this is q dirty fix because conditions are more and is difficult to use multiple times for updating record.
I'm recieving the following error on trying to run an append query in access.
Microsoft Office Access set .... and it didnt't add... 779280 records(s) due to validation rule violations.
If I choose to run the query anyways, nothing actually happens.
To give some context, I'm simply trying to copy a populated field, consisting of values similar to "16-2009-02, 34-2010-02, et cetera" to another currently unpopulated field.
The fields themselves have no set validation rules, and both have the standard text field options.
I'm hoping to be able to simply remove those hyphens, and fix the issue. But I guess that's what I'm not sure about, are those hyphens actually a problem?
Running SP3 w/ Access 2003.
Thanks in advance!
Does the destination field have Allow Zero Length set to false or Required set to true? If it does, it is possible that some of the data from the source column is null or is set to an empty string. In addition, you should verify that the field sizes on the new column is equal to larger than the source column.
EDIT On appending from one table to another, you must ensure that you populate the columns that makeup the primary key of the destination table. Thus, from your screenshot, you need to include the loggerid and datetime columns from the "Log ID" table. Now, if there are collisions, Access should tell you how many rows generated collisions and let you append the ones that did not collide with the uniqueness restriction on loggerid and datetime
Make sure the target column is not indexed or, if it is, that duplicates are allowed. Access often makes indexing decisions on your behalf and sometimes they are not correct.
MS Access appears to support nulls in code, but I can't for the life of me figure out how to enter a null directly in a table. This is maddening because once a field has had a figure entered in it, it can never be deleted/set to null. Normally, allowing zero length strings would take care of this, but Access treats the XML export of a null and a zero length string differently. A null eliminates the associated XML tag and a zero length string sends an empty tag.
Does setting the "Allow zero length string" option in the table definition help? It may force an empty string to be interpreted as NULL.
Are you talking about needing to do it in Datasheet view? If you needed to do it in an update query, you can do it like this:
UPDATE test SET test.test = Null;
press ctrl-0 and a null is inserted.
Deleting all the characters will work, but Access is a bit fickle. Hitting backspace or delete will not work unless there are characters in the field. I find it is best to enter a few characters, select all, and hit delete, change focus and change the record. After all the above, if you run a query looking for "is null" the record will be found.
I'm actually looking for a way for a layperson to do the entry directly in a table. In MSSQL you can simply press ctrl-0 and a null is inserted. Deleting all the characters doesn't appear to work. Instead of a null, you are left with an empty string. They are not treated the same by Access for export purposes.
I think what I'm going to wind up doing is creating an xslt file to use during export that eliminates empty tags. That way the user can't really tell the difference.
It sure would be nice, though, to be able to key in a null.
Ok, I don't think this is an easily solvable problem and my original question was a little off target. The problem isn't so much with nulls, although they are involved, as with the manner in which the table was originally created. If you use an xsd file to create your tables you plan on exporting, something happens under the hood in Access that causes those fields to be treated a little differently than fields created with the editors.
The only solution I found was to create a new field in the table, rename the old field, copy the data from the old field to the new field and delete the old field.
After doing that, then blank fields that had data in them at one point are no longer included in the XML output. It's probably not the best way to do this, and I still don't know exactly why it's happening, but at least I can get past the issue.
Just delete all characters in the column and access will insert a null value for you if the coumn allows it.