samuel
10/29/2002 3:14:00 PM
Shawn,
Regarding the ODBC transactions what I noticed is:
scene A
---------
when the TRANSACTION performs 2 different operations (1
insert, 1 update) the ODBC.NET executes the transaction
and commits the data
scene B
---------
when within the TRANSACTION there are 2 or more equal
operations (2+ updates), the ODBC.NET HANGS exactly where
the 2nd cmd_req.ExecuteNonQuery() statement is. The data
is not commited, and you don't have any timeout event
happening.
This particular system is under construction - so I don't
have any heavy traffic at all. My current settings are:
- Informix 7.31 (running on a SCO box)
- MDAC 2.7
- Informix ODBC Driver 3.81 32 BIT (3.81.00.11267 IBM
Corporation. File: ICLIT09B.DLL release date: 6/19/2002)
- my machine is a Windows XP Professional, and the ODBC
Manager version is 3.520.7713.0
----------------------------------------------------
About your questions:
----------------------------------------------------
>Interestingly i've never been able to connect to
informix using oledb. I am using informix 5.1 and i will
soon be upgrading to 7. Hopefully that will clear up my
problem.
yes, we were able to use OLEDB since day 1, BUT as you
can see in other entries I submitted to this managed
forum, under moderate traffice, the OLEDB manager gets
lost and after a few open/close connection operations, it
is impossible to open a new connection. That's our reason
to move back and adopt ODBC.NET. Now we are having this
issue with Transactions, while (when the connection is
posssible with OLEDB) the transactions were performed
without any problem. Crazy, isn't it?
> Did you have any major problems when you were setting
up to connect to oledb?
No, it was very easy to set it up. I strongly recommend
that you remove the previuos driver and DSNs from your
machine before installing the new one.
----------------------------------------------------
Thank you for your reply,
Samuel
>-----Original Message-----
>I am using transactions and i don't seem to be having
any problems. All
>transactions seem to go through just fine. Do you only
see your issue under
>higher volumes of transactions or all the time. I am
using 3.80.
>
>Interestingly i've never been able to connect to
informix using oledb. I am
>using informix 5.1 and i will soon be upgrading to 7.
Hopefully that will
>clear up my problem. Did you have any major problems
when you were setting
>up to connect to oledb?
>
>I guess it's possible that there is a driver issue with
transactions. I'll
>have to keep that in mind when testing.
>
>Shawn
>
>
>
>"Samuel" <sqlman@hotmail.com> wrote in message
>news:ab4801c27aa2$d9ccbf40$37ef2ecf@TKMSFTNGXA13...
>> I'm developing a project with .NET to access INFORMIX
>> (7.31). When I started the project I was using
OLEDB.NET,
>> the performance is GREAT, but when using the system in
>> production mode - the IIS server loses the connection
to
>> Informix several times a day. The only way to fix this
>> problem was reseting the IIS...
>> My next approach was to move to ODBC.NET and I don't
have
>> this problem that you mention (about loosing content
from
>> a CHAR field), but I do have problems in trying to
>> execute a TRANSACTION.
>>
>> The Informix driver I'm using is 3.81. You can get this
>> new driver from IBM/Informix downloading the Client DSK
>> 2.8. But before installing this version, remove all
DSNs
>> that you have with your current driver, then install
the
>> new C-SDK and recreate the DSNs.
>>
>> Do you have any code using TRANSACTIONS ?
>>
>> Samuel
>>
>> >-----Original Message-----
>> >Hi Everyone,
>> >
>> >I'm wondering if anyone has seen this issue before.
I'm
>> using odbc.net to
>> >connect to informix. I seem to be losing data when i
try
>> to get the data
>> >inside of a char field. It seems that if my CHAR field
>> is defined to size
>> >10, I only get 5 characters back. If i define it as
size
>> 20 then i get 10
>> >characters back. ODBC.net seems to think that the data
>> is only half as long
>> >as it is. Has anyone seen/fixed this before?
>> >
>> >Thanks,
>> >Shawn
>> >
>> >
>> >.
>> >
>
>
>.
>