Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread Error 700 in EDBMgr
Tue, May 24 2011 1:44 PMPermanent Link

David Cornelius

Cornelius Concepts

Avatar

I'm in the process of developing an upgrade to my customer's application.
They are currently on EDB 2.03 and because of frequent replication needs,
I'll be upgrading them to EDB 2.05 in order to generate updates with the "IF
NOT EMPTY" clause.

I've got a script that backs up their database and restores it to my local
server every night so I can always test with their latest data.  Since I've
already upgraded my server to EDB 2.05, I need to be aware of the breaking
changes in 2.04 and 2.05 while pulling in their 2.03 database.  I thought
that I could at least browse their data without any problem.

What happened, though, is every table, function, and stored procedure I
click on in EDB Manager (2.05 b7) raises the following error:  ElevateDB
Error #700 An error was found in the function at line 13 and column 31
(Expected array variable name, array variable element name, or variable name
expression but instead found "Version").

As I was going through the process of figuring out how to get rid of this,
the error sometimes mentions a procedure instead of function, a table name
instead of "Version" or a different line and column number.  I eventually
had to write a script to update all the stored procedures and functions to
the new syntax before I could even browse my database.

I'm not complaining or submitting a bug, just pointing out something that
surprised me for a bit until I worked it out.  I suppose if there's anything
I could ask for improvement on, it would be to list the object in the error
message that was causing me grief.  Fortunately, I don't have a very large
number of procedures, but it was still tedious going through every one and
figuring out which ones I needed to upgrade (I eventually found 4 functions
and 19 procedures that needed upgrading).


David Cornelius
Cornelius Concepts
Wed, May 25 2011 3:25 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

David


Is this the one where you have to stick quotes around things?

Roy Lambert
Fri, May 27 2011 12:28 AMPermanent Link

David Cornelius

Cornelius Concepts

Avatar

Yeah.  In procedures with cursors or transactions.

David Cornelius
Cornelius Concepts


"Roy Lambert"  wrote in message
news:7F8B0C37-0B5B-468B-B101-F6C4359153D1@news.elevatesoft.com...

David


Is this the one where you have to stick quotes around things?

Roy Lambert
Tue, May 31 2011 4:01 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

David,

<< What happened, though, is every table, function, and stored procedure I
click on in EDB Manager (2.05 b7) raises the following error:  ElevateDB
Error #700 An error was found in the function at line 13 and column 31
(Expected array variable name, array variable element name, or variable name
expression but instead found "Version"). >>

Did you alter any of the procedures or functions in your database ?  EDB
will use the older version of a procedure or function, as long as you don't
alter it.  Once it is altered, EDB expects it to use the newer syntax for
the cursor-based INSERT, UPDATE, and FETCH statements.

--
Tim Young
Elevate Software
www.elevatesoft.com
Wed, Jun 1 2011 1:28 AMPermanent Link

David Cornelius

Cornelius Concepts

Avatar

No--and that's the curious thing that prompted the newsgroup post.  My
nightly scheduled job restores my customer's backup onto my local database
server.  The local database server is running 2.05 and my customer's
database is 2.03.

Without doing anything else, I open EDB Mgr 2.05 to look at the server
database (the restored 2.03 now running under 2.05) and I start getting the
errors.  I now have a script I immediately run to convert everything, but at
first I was getting the error on every single database object.

When this first happened, I started fixing and recompiling each procedure.
The error would then change to indicate the next error it found.  Sometimes
I would fix two or three procedures and the error wouldn't change until I
finally fixed the next one that EDB was hung up on.  The main reason I
complained is that I didn't know which procedure was causing the currently
displayed error until I happened to fix that one and saw the error change.

I'm guessing the act of restoring the database recompiled the procedures
with the errors.  If I had simply opened the remote database, perhaps it
would've been happy, but I don't want to take the chance of messing with my
customer's database and I don't want to take the time to setup EDB 2.03 on a
virtual machine just to test it out--especially now that I've got it
resolved.

David Cornelius
Cornelius Concepts
Wed, Jun 1 2011 11:04 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

David,

<< I'm guessing the act of restoring the database recompiled the procedures
with the errors. >>

Restoring a database and including the catalog doesn't recompile the
procedures, but it does re-load the catalog for the current database, and
that is what will update the catalog version to the latest version.  The
solution is to not include the catalog in the restore operation for the
database.

--
Tim Young
Elevate Software
www.elevatesoft.com
Thu, Jun 2 2011 1:18 AMPermanent Link

David Cornelius

Cornelius Concepts

Avatar

Good to know--thanks for the explanation!

David Cornelius
Cornelius Concepts
Image