Hi,
I checked some of my Windows tafs for Witango 5.5 and found a few
listed
below. Is it correct in assigning this DataType for an "as" variable?
Thanks
Steve Fogelson
Internet Commerce Solutions
<Column DataType="!CST" ColumnType="0">
<TableName />
<ColumnName><![CDATA["Products.P_Oversize as FType"]]></ColumnName>
</Column>
<Column DataType="!CST" ColumnType="0">
<TableName />
<ColumnName><![CDATA["Products.P_ID as FID"]]></ColumnName>
</Column>
-----Original Message-----
From: Peter Ternstrom [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 20, 2005 11:10 AM
To: [email protected]
Subject: Re: Witango-Talk: OS X.4 - Danger in correcting... (solved)
Hello All,
i have also seen the !CST in my tafs for a while now (Win 5.5 / 5.08).
When I investigated the problem I found that all !CST in my
application
files were from tables and fields that were newly introduced in the
database, probably added in the database while writing the taf and
then
refreshed the table structure to see the changes (and directly
dragging
them
in actions). The problem could also be due to the fact I was using the
same
data source name for two versions of the same application. The two
versions
had slight changes in the database - the difference between them were
indicated by !CST in the tafs for the new version.
I also found that witango editor might keep table field names in the
taf-file although they are not visible in the editor or exist in the
database.
Im not sure how it works in other environments, but with MS SQL
witango
studio will show the dbo prefix in front of table names in the
"details"
column of database actions. Sometimes it would remove the dbo prefix,
just
showing the table name(s) used in the query. This behavior was to me
quite
random, before I found out that it was related to the !CST problem.
Yes
-
when you had !CST errors in your query it would remove the dbo
prefix in
the
details column.
The concusion is that it seems to be some kind of problem with caching
of
the table structure in witango studio. I really dont care. The most
important thing is that i found a way to solve it:
The solution is to create a new datasource for the database you are
working
with and use "set data source" on all the queries in your project,
pointing
to the new datasource. This corrects all !CST errors in your tafs,
including
other related problems/errors. It might take a while, but it sure
beats
using a text editor and manually replacing them.
Peter
----- Original Message -----
From: "Dale Graham" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, October 20, 2005 4:58 PM
Subject: Re: Witango-Talk: OS X.4 - Danger in correcting...
After editing the TAFs / TCFs (with a text editor, BBEdit), I found
that
some tafs now had a "corrupted structure" as reported by the Witango
server. If I just created a new TAF and dragged over the actions
from
the
old one, the TAFs ran correctly. But when I examined the XML for the
re-created TAF, our friend "!CST" had reappeared (more or less
randomly,
as far as I could tell - that is not all datatypes were incorrectly
changed). If I attempted to change this back via the text editor, it
rendered the files once again as corrupted structure.
If, on the other hand, I re-created the problematical update/insert
actions, the problem was solved (TAF is not corrupted, correct
datatypes
reported in Data Dictionary)
NOT looking forward to making tons of changes. Grateful that I put
all my
files under Subversion control just before starting the changes via
text
editor!
On Oct 20, 2005, at 7:51 AM, Dale Graham wrote:
I checked my files for the !CST characters and sure enough, I DID
find
them throughout recently edited TAFs and TCFs. We haven't seen
much
instability in our production instance that could be related to
inserts
and updates, but perhaps this was because we are not using the
Witango
server, but rather the Witango servlet.
I have been spending my morning replacing the !CST characters but
brooding abt the fact that each time I edit or add a new search/
insert/update I might be adding something to edit later...
So, no, there's no database "protective" effect from using Oracle
and or
JDBC connectors. Same issue.
On Oct 20, 2005, at 6:43 AM, Robert Garcia wrote:
I have seen it with primebase, and MSSQL 2000, and MYSQL.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Oct 20, 2005, at 3:08 AM, Dale Graham wrote:
We're using Tiger 10.4.2 and Oracle via JDBC, and have never
experienced insert or update action corruptions. Could this be
database and/or DB connector related?
We do occasionally see a tcf object's scope get "lost" shortly
after
being added to a TAF, but after it gets changed once (or twice)
back,
it finally "sticks" and we no longer have an issue with it.
On Oct 19, 2005, at 6:22 PM, Bill Conlon wrote:
Thx much. I found a used dual G4 1.25 GHz for the price of a
mini,
so I'll probably stick with X.3.9.
BTW, I've never had the corruption issue while running X.2.8.
bill
On Wednesday, October 19, 2005, at 03:00 PM, Robert Garcia
wrote:
I do, and there are others, like Mark Weiss and Roland.
There is a serious bug that I don't think is JUST 10.4, but
seems to
show up more in 10.4. Your insert and update actions can get
corrupted. It is a major pain, it has been reported to Witango
months ago. It has not been acknowledged, and none of (AFAIK)
have
heard from witango on this.
See previous posts for more details on the bug.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Oct 19, 2005, at 12:32 PM, Bill Conlon wrote:
I think I'm ready to migrate from my circa 1998 G3 desktop.
Can't
remember which feline is the current version, but does anyone
have
experience running the Dev Studio on X.4?
thx
bill
_________________________________________________________________
_______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
__________________________________________________________________
______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
___________________________________________________________________
_____
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
____________________________________________________________________
____
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
_____________________________________________________________________
___
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
