DISREGARD -> Problem using TIME datatype in dbproc

Never mind, I thinks me found the problem with this old hacked up dbproc. thanks anyway. -Original Message- From: Kevin Wilson Sent: Friday, October 07, 2005 11:36 AM To: Maxdb (E-mail) Subject: Problem using TIME datatype in dbproc Importance: High Why does this return "Integrity cons

Problem using TIME datatype in dbproc

Why does this return "Integrity constraint violation;-8006 POS(1) Data types must be compatible"? The field in rectbl is a TIME datatype. CREATE DBPROC SP_UPDATE_TIME( IN REC_ID FIXED (10,0), IN UPDTIME TIME ) AS UPDATE MYDB.RECTBL SET UPDTIME = :UPDTIME WHERE REC_ID = :REC_ID;

FW #2: OS question concerning Failover setup

>From the standby docs (homogeneous backup) the matrix shows that 64x64 Linux will work together regardless of kernel version so this implies to me that I should be able to use Linux 9.3-64 as a standby server to my Linux 9.2-64. Now this raises another question, do the database instances have to

FW: OS question concerning Failover setup

Sorry but I meant inquire for both a regular standby server and a hot standby (clustered solution). -Original Message- From: Kevin Wilson Sent: Friday, October 07, 2005 9:29 AM To: Maxdb (E-mail) Subject: OS question concerning Failover setup I have maxdb running on SuSE 9.2 64bit w/ AM

OS question concerning Failover setup

I have maxdb running on SuSE 9.2 64bit w/ AMD Opteron hardware and I want to setup my other duplicate server using 9.3 64bit ... can I do this and still use the 9.3 server as the hot standby server? -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe:

AW: dbproc behaviour after drop and (re)create table

Jean-Michel OLTRA wrote : >bonjour, > > >Le vendredi 07 octobre 2005, Anhaus, Thomas a écrit... > > >> objects have no knowledge about the db-procedures using it. >> This means that today you have to recreate the db-procedures by hand >> whenever a change of an object accessed inside >> the p

Re: dbproc behaviour after drop and (re)create table

bonjour, Le vendredi 07 octobre 2005, Anhaus, Thomas a écrit... > objects have no knowledge about the db-procedures using it. > This means that today you have to recreate the db-procedures by hand > whenever a change of an object accessed inside > the procedure requires it. What does "r

AW: dbproc behaviour after drop and (re)create table

Jean-Michel OLTRA wrote : > >bonjour, > > >I had problems with a dbproc using python (the insertion performed by >the dbproc skipped NEXTVAL). > >I dropped the table, and reloaded data. > >Then I tried to insert a record using my gui, and got an error : >"invalid date format : INTERNAL". The da

dbproc behaviour after drop and (re)create table

bonjour, I had problems with a dbproc using python (the insertion performed by the dbproc skipped NEXTVAL). I dropped the table, and reloaded data. Then I tried to insert a record using my gui, and got an error : "invalid date format : INTERNAL". The date field inserted is _not_ invalid.

Re: DELETE fails from sqlcli but not from SQL Studio

2005/10/7, "Döhr, Markus ICC-H" <[EMAIL PROTECTED]>: > > * -4008: Unknown user name/password combination SQLSTATE: > > 08004 sqlcli=> > > Did you just start sqlcli or did you also logon as you did in SQLStudio? LOL I'm sorry, this was a copy and paste error. Here's the "correct" error message:

RE: DELETE fails from sqlcli but not from SQL Studio

> * -4008: Unknown user name/password combination SQLSTATE: > 08004 sqlcli=> Did you just start sqlcli or did you also logon as you did in SQLStudio? Greetz, SIEGENIA-AUBI KG Informationswesen i.A. Markus Döhr SAP-CC/BC, SAPDB-DBA Tel.:+49 6503 917-152 Fax: +49 6503 917-7152 E-M

DELETE fails from sqlcli but not from SQL Studio

Hi again, I see this error: sqlcli=> DELETE FROM cr_admin.ag_url > WHERE NOT EXISTS ( > SELECT urlid >FROM cr_admin.url_cleanup > WHERE cr_admin.url_cleanup.urlid = cr_admin.ag_url.urlid > ) > \g * -4008: Unknown user name/password combination SQLSTATE: 08004 sqlcli=> MaxDB 7.