Hi all,
Got an import function that i'm bust trying to fix on 5.5r518 on Win2003 with SQL2005 as a database. This error pops up and the documentation from ProIV does not include this error code. Anybody experienced this or have an idea on what might be causing it?
Thanks
Click the link below to see the new game I'm developing!
8 replies to this topic
#3
Chris Mackenzie
-
- Members
-
- 372 posts
ProIV Guru
- Gender:Male
- Location:Bristol, United Kingdom
Posted 10 May 2007 - 01:17 PM
Anyone?
Seems not. v6 docs don't have this either. Round
up the usual suspects.
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.
of the poster and do not represent those of any organisation.
#4
andykay
-
- Members
-
- 204 posts
ProIV Guru
- Gender:Male
- Location:Cyberspace...looking for work
Posted 10 May 2007 - 05:04 PM
Google says that a SQL357 Error has to do with your function trying to access a file server that is currently not available.
As ProIV's exceptionally well documented error codes seem to have missed this one, perhaps you should check out side the realm of ProIV for your answer.
GL,
AK
As ProIV's exceptionally well documented error codes seem to have missed this one, perhaps you should check out side the realm of ProIV for your answer.
GL,
AK
#5
Chris Mackenzie
-
- Members
-
- 372 posts
ProIV Guru
- Gender:Male
- Location:Bristol, United Kingdom
Posted 11 May 2007 - 08:33 AM
Google says that a SQL357 Error has to do with your function trying to access a file server that is currently not available.
As ProIV's exceptionally well documented error codes seem to have missed this one, perhaps you should check out side the realm of ProIV for your answer.
GL,
AK
Andy - in what context does SQL 357 mean that? It's not an SQLSERVER error number.
The err is issued by Pro-IV I don't see how checking ''outside the realm of ProIV' could
help?
The documented P4 error messages go 353,354,360
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.
of the poster and do not represent those of any organisation.
#7
Richard Bassett
-
- Members
-
- 707 posts
ProIV Guru
- Gender:Not Telling
- Location:Rural France
Posted 14 May 2007 - 04:42 PM
Neil,
I don't use SQL/Server but I can tell you what this message was supposed to mean for ProIV on Oracle because this functionality was added in V4 at my request
Essentially it means you are trying to write (update or delete) a record on which you no longer have a lock.
This would normally mean your function has caused a commit before it was safe to do so.
The result of this is that you have (or should have) lost the "write currency" on any files where writes were pending.
(In "generic" SQL terms, a WHERE CURRENT OF CURSOR clause no longer identifies any record.)
Aside: In a comparable way, "Fetch out of sequence" is where you have lost read currency because of a transaction boundary and so your attempt to fetch another row fails.
The way the ProIV-Oracle interface was implemented (for performance), a write like this could succeed even though it is unsafe.
To avoid that danger ProIV will generate this error 357 if your code attempts such a write.
Unfortunately this was only the case when environment variable SQL_TRANSACTION_ERROR was set to Y.
Consequently, ProIV/Oracle applications should always set that variable!
I don't know if this will be the same for SQL/Server. The reason for the message is very likely to be the same but maybe ODBC-based stuff always fails as it should and isn't dependent on any particular environment variable.
HTH, Richard
PS: Be glad you're not using non-transactional C-ISAM where these unsafe writes will occur silently if you write to the same physical file in more than one place in your function
I don't use SQL/Server but I can tell you what this message was supposed to mean for ProIV on Oracle because this functionality was added in V4 at my request
Essentially it means you are trying to write (update or delete) a record on which you no longer have a lock.
This would normally mean your function has caused a commit before it was safe to do so.
The result of this is that you have (or should have) lost the "write currency" on any files where writes were pending.
(In "generic" SQL terms, a WHERE CURRENT OF CURSOR clause no longer identifies any record.)
Aside: In a comparable way, "Fetch out of sequence" is where you have lost read currency because of a transaction boundary and so your attempt to fetch another row fails.
The way the ProIV-Oracle interface was implemented (for performance), a write like this could succeed even though it is unsafe.
To avoid that danger ProIV will generate this error 357 if your code attempts such a write.
Unfortunately this was only the case when environment variable SQL_TRANSACTION_ERROR was set to Y.
Consequently, ProIV/Oracle applications should always set that variable!
I don't know if this will be the same for SQL/Server. The reason for the message is very likely to be the same but maybe ODBC-based stuff always fails as it should and isn't dependent on any particular environment variable.
HTH, Richard
PS: Be glad you're not using non-transactional C-ISAM where these unsafe writes will occur silently if you write to the same physical file in more than one place in your function
Nothing's as simple as you think
#8
Neil Hunter
-
- Members
-
- 420 posts
ProIV Guru
- Gender:Male
- Location:Johannesburg, South Africa
Posted 15 May 2007 - 10:01 AM
Thanks Richard, that was exactly it!
Our transaction file is in descending date order sequence and rows are inserted via a global update with a commit at the end of the GU, and then data is added afterwards.
Our transaction file is in descending date order sequence and rows are inserted via a global update with a commit at the end of the GU, and then data is added afterwards.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
Click the link below to see the new game I'm developing!
