Default field value

[Cristiano]

Hi guys,

I have to set a field in a table to "1", this is to lookup the table with other tables. So far nothing difficult, I put as default rules into this field to "1", and it works but only if the records are inserted manually

I must, however, to update this table through a data import that goes automatically to populate this table and when some amount of data are inserted automatically through a data import, the field that should always be set to "1" is not set on this mode. why? I have wrong something?

Thank you for your suggestions

[Cristiano]

Re: Default field value

Hi,

I solved it. I do not know if this is the correct method but it works.

I have insert into my scrpt this two lines:

append.m_field22 = "my_field_name"
Append.m_exp22 = "1"

Thank you and Happy new year

[Raymond Lyons]

Re: Default field value

Cristiano,

Arguably, whatever works is correct! However, you didn't have to convert your append to xbasic. You could have just put 1 (or "1" if it is a character field) as an expression for that field in the append operations builder. Or, instead of having a default of 1 in the table field rules, make it a calculated field in the table field rules with a value of 1. The latter way would probably cover all bases whereas doing it in an append only works there.

Ray Lyons

[Ted Giles]

Re: Default field value

Have you set the Default value action correctly?
On date entry, If not touched?
2 check boxes in the Field Rules.

[SNusa]

Re: Default field value

As I recall, there is an "unexpected situation" that also can render field rules "ineffective." They are only applied when at least one field of a .dbf table is manually entered.
More info (and other v.11 bugs) here: http://msgboard.alphasoftware.com/al...l=1#post610372

I built a little tool to explore browse behavior which documented events as they fired. (It reported all events, including all table and field base ones of the underlying table itself.) This tool exhibits some STRANGE and unexpected behavior at times. Particularly with regards to the number of events that fire when you're navigating with a keyboard versus with a mouse. It also left me with the opinion that data entry in a browse is best accomplished with an embedded button in the browse. (I've made some buttons hidden, so that they just look like the regular record field.) Also, when setup properly, you can use some field and record level events instead of browse level events (but this is tricky, advanced, and not recommended, not to mention there can be differences in how many/which events are triggered depending on whether you use the keyboard or the mouse!) ~ I just remembered one instance where the number of events firing at the table/record level changes: It's when (how actually) you go about "marking" records..... (still an anomaly in the latest (final ) "nightly build" version of v.11)

Just thought I'd share the above info with regards to when "field rules are not invoked." (The link above contains a list of other v.11 bugs I encountered. The more recent ones include problems that were fully documented and submitted but were never fixed. - I tried!) I spent a "boatload" of time trying to figure out exactly what was unexpectedly happening (when and why). And since the issues were never fixed, I hope I can at least save other from the frustrations I encountered.....

On that note: In certain "configurations", browses exhibit some other strange behaviors too... At least one of the browse events does not "fire" on the first record when a browse (on a form) first gets "focus." (the first row first time it becomes activated) ~ That reminds me: You'll also experience alll sorts of browse display (and inaccurate summary field calculations) if the browses "parent record only" property/attribute option is unchecked on a browse built from a set. (You'll also experience scroll related issues, and "field ghosting" with this unchecked. Moving through the browse won't work properly, and as you do at least one of the field values may unexpectedly change in the browse. You won't be able to scroll down all the way either. ~ The only way to see all the records is to expand the browse container. (something you can't do if the browse is embedded in a form)

PS: I have these apps if anyone wants to "see for themselves." These are issues (along with the apps exhibiting this behavior) were submitted eons ago, but were never "addressed" in v.11. (I hope/was told by sales, that all "unfixed v.11 bugs" were being addressed in v.12 - even on the classic desktop side.) I haven't checked yet, but I most certainly will once I "get the courage" to install v.12.....