Jump to content


Photo
- - - - -

SQL 357 Error


8 replies to this topic

#1 Neil Hunter

Neil Hunter

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 414 posts
  • Gender:Male
  • Location:Johannesburg, South Africa

Posted 10 May 2007 - 05:17 AM

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

#2 Neil Hunter

Neil Hunter

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 414 posts
  • Gender:Male
  • Location:Johannesburg, South Africa

Posted 10 May 2007 - 12:04 PM

Anyone?

#3 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • 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.

#4 andykay

andykay

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 204 posts
  • 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

#5 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • 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.

#6 Fred Marker

Fred Marker

    Advanced

  • Members
  • PipPipPip
  • 82 posts
  • Gender:Male
  • Location:Columbus, Ohio, United States

Posted 11 May 2007 - 12:20 PM

Does v5.5 support SQL 2005? I thought that it required v6!?!

#7 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • 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 :unsure:
Nothing's as simple as you think

#8 Neil Hunter

Neil Hunter

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 414 posts
  • 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.

#9 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 396 posts
  • Gender:Male
  • Location:Florida,USA

Posted 12 August 2015 - 06:52 PM

Just got this error in our development environment. Thanks for posting the solution. :D


Things should be made as simple as possible, but not simpler



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users