I got a lite license, and I can't reproduce. I asked Mark to create
the taf with me watching via tb2, to see if there was something
unusual he did. One thing he did, that I never do, is he right
clicked inside the field area of insert and selected insert meta tag,
and chose current timestamp that way. I have never done that, but I
could not reproduce. I lent mark a copy of my standard key, and now
he doesn't seem to be having the problem, so far.
( I trust mark, he will dispose of my key or purchase on his own.)
However, if this is a lite issue, I don't think users should have to
pay to get around this.
I guess a workaround is to open the taf in a text editor and check
for !CST in the datatype, and manually fix with the right datatype.
--
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 Jul 15, 2005, at 12:32 AM, Robert Garcia wrote:
It is definitely the studio.
I had Mark create a taf on his system that did a timestamp insert,
and it worked, then he renamed the insert action, and it did not.
So I had him send to me, then I opened a copy, rebuilt the insert
in my studio. I tested, his failed on my system, whether on windows
or whatever, and mine worked.
So I compared the xml of each, and here is what I found.
Here is the datadictionary on the GOOD taf:
<DataDictionary>
<Column DataType="vcha" ColumnType="0">
<TableName>phonelog</TableName>
<ColumnName>RVORefNumber</ColumnName>
</Column>
<Column DataType="tims" ColumnType="0">
<TableName>phonelog</TableName>
<ColumnName>PhoneLogged</ColumnName>
</Column>
</DataDictionary>
Here is the DataDictionary of the insert on the bad taf:
<DataDictionary>
<Column DataType="!CST" ColumnType="0">
<TableName>phonelog</TableName>
<ColumnName>RVORefNumber</ColumnName>
</Column>
<Column DataType="!CST" ColumnType="0">
<TableName>phonelog</TableName>
<ColumnName>PhoneLogged</ColumnName>
</Column>
</DataDictionary>
The data types are clearly messed up, don't know what !CST means,
but it should be varchar and timestamp. So this is the issue. Mark
is using Lite version of studio, I am using licensed version.
Anyone else seeing this problem, what version of the studio are you
using?
--
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 Jul 14, 2005, at 9:43 PM, Robert Garcia wrote:
if you have a taf, that does this error, send it to me at
[EMAIL PROTECTED] if you can. So you are saying you see the same
issue with your datasources?
I don't think it is the studio, cuz then I would see this problem,
as I develop on OS X studio, but so far, all those who have this
problem that I have seen are running the Witango OS X server.
Unless the studio produces a difference in the xml in the taf. But
why doesn't mine? So if you have one that exhibits this error, I
will compare with others. A simple taf preferably.
--
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 Jul 14, 2005, at 9:26 PM, Christian Platt wrote:
Hi Robert,
you are right. For me the Studio is the suspect.
I use the following surroundings... (all JDBC)
Witango/Frontbase
Witango / Mysql
Witango/ OpenBase
I noticed that with FrontBase an OpenBase an i thought about
having to do with JDBC, but if that happened to you with ODBC
connections, it must be an effect of the Insert Action in the
Studio.
Christian
Am 14.07.2005 um 15:59 schrieb Robert Garcia:
Exactly, but you should not have to edit the timestamp with a
format. as in my case, it should escape the timestamp on insert
and update. And Mark, has seen the problem not consistent
either. What database are you using?
I am suspecting it is a bug in Witango OS X. I am thinking of
setting up a test environment, and try to reproduce with more
than one dbms, and try with JDBC. And see what the results are,
but I would like to here from witango support first.
--
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 Jul 14, 2005, at 6:42 AM, Roland Dumas wrote:
I was just fiddling with such a case yesterday and have had the
problem on and off for quite a while.
I insert a timestamp and nothing gets to the db. I edit the
timestamp to include a format=datetime: xxxx and it works. If I
edit that action again, it may stop working and then reverting
to the plain timestamp format works.
been that way for a while
On Jul 13, 2005, at 11:00 PM, Robert Garcia wrote:
I am helping another witango user(Mark Weiss), with a setup of
OS X 10.3.9 server with 5.5.009, Openlink iODBC 3.52.1
connecting to Primebase 4.2.49 also running on OS X.
The issue has to do with errors inserting timestamps. I made a
test with my setup, which is identical, 5.5.009, and Primebase
4.2.49, but I am using Windows, not OS X.
I have checked the setup of his database server, and the
witango server, and they are setup the same as mine, but look
at debug when he inserts a timestamp:
_________________________________________________________________
_______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
<pastedGraphic.png>
Normally, I would see the timestamp escaped, like this below,
a test from my system:
<pastedGraphic.png>
I VERIFIED that both test were inserted with action like so:
<pastedGraphic.png>
So, why is witango escaping on mine, and not his system? Does
witango escape when certain conditions apply with ODBC? What
are those conditions, so I can check with Primebase? When I
use other tools, I do not see issues with ts inserts, and I
have verified that both ODBC/DB systems on both machines are
expecting date in YYYY-MM-DD HH:MM:SS, standard SQLTimeStamp
format.
I have verified that on the OS X system, mark did not alter
the DB so that it looks for a different format.
Hoping Support, or someone on the list may have some insight.
--
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/
--
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/
__________________________________________________________________
______
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
