SQL Anywhere ultralite - Schema ApplyFile Problem

Author

Schema ApplyFile Problem

Carl Langren

2006-02-07, 11:23 am

Good morning.

We are using:
WinXP with VisualStudio 2003, current on SP's
AppForge Crossfire (similar to MobileVB but the .Net flavor) v5.6.1
SQL Anywhere 9.0.2.2451 (OEM) current OEM release, I believe.

I reviewed the previous posts on issues with ApplyFile in v9.0.2.2451, but
it does not appear the indicated work around can readily be implemented
using the iAnywhere. UltraLiteForAppForge
component. It may not even be
applicable given the overlap or lack thereof in codebase. Additionally, our
problem is a bit different.

We are preparing for the deployment of an upgrade to an inplace UltraLite
database supporting our application. This is our first upgrade to the
database in its deployed form. We have reviewed the documentation for the
use of Connection.Schema.ApplyFile() as it pertains to MobileVB. We can
successfully monitor the OnSchemaUpgradeState
Change and
OnSchemaUpgradeProge
ss events.

Our problem is we cannot get a ULSchemaUpgradeState
of ulUpgradeStateDone,
i.e. integer value 3. We go from 0 to 1 and then (after about 30-35 seconds)
we go to ulUpgradeStateError,
i.e. integer value 4.

We get this state (ulUpgradeStateError
) even when we try to apply the .usm
which was used to
create the .udb back onto the .udb. The documentation indicates this action
should be ignored by the call to ApplyFile if the .usm has already been
applied.

To add to (my) the confusion, if we take the .usm used to create the .udb,
add a column to a table (or two) and create a new .usm, ApplyFile that new
..usm to the original .udb, the database is actually updated successfully.
The columns we added to the schema and applied to the database are
successfully created by the ApplyFile call.

My main questions / observations: What am I missing? It appears to work, but
how do I program to check for errors? Is there anything else I can monitor
or check re: the process of applying the upgrade and related errors?

====================
====================
=
Other Questions re: use of ApplyFile and .usm's post upgrade:
====================
====================
=

1.) I could not get the ApplyFile to execute until I actually disconnected
and reconnected the database. I am guessing this is a function of my code
and desire to "check a few thinks" before the upgrade rather than a
functional requirement for the call? Is it a requirement to disconnect from
the database and reconnect if you perform any database operations prior to
performing the ApplyFile?

2.) If our current database and schema are 1.udb/1.usm and our new schema is
2.usm, after we call ApplyFile with 2.usm specified for application to the
current connection, have both 1.udb and 1.usm been upgraded? or only 1.udb?
We would use 2.usm to create the .udb in new deployments, but when
specifying the connection parameters for the upgraded 1.udb (post
application of 2.usm), must the 2.usm be specified in the connection or will
both 1.usm and 2.usm work?

Thanks,
Carl

Michael Thode

2006-02-08, 11:23 am

What is the sqlcode after you get the failures?

1. Most likely you have something left open when you call ApplyFile().
This is probably why disconnecting and reconnecting fixes the issue as it
forces everything to close. No table, schema, preparedstatement or
resultset objects can be open when ApplyFile() is called.

2. .usm files are only used to create databases. If the database already
exists than any .usm parameter in the connection string will be ignored.
The schema is loaded into the udb file when the db is created or ApplyFile
is used. After an upgrade you can delete the .usm if you wish.

Mike

"Carl Langren" < clangren_nospam@worl
dnet.att.net> wrote in message
news:43e8d8d1$1@foru
ms-1-dub...
> Good morning.
>
> We are using:
> WinXP with VisualStudio 2003, current on SP's
> AppForge Crossfire (similar to MobileVB but the .Net flavor) v5.6.1
> SQL Anywhere 9.0.2.2451 (OEM) current OEM release, I believe.
>
> I reviewed the previous posts on issues with ApplyFile in v9.0.2.2451, but
> it does not appear the indicated work around can readily be implemented
> using the iAnywhere. UltraLiteForAppForge
component. It may not even be
> applicable given the overlap or lack thereof in codebase. Additionally,
our
> problem is a bit different.
>
> We are preparing for the deployment of an upgrade to an inplace UltraLite
> database supporting our application. This is our first upgrade to the
> database in its deployed form. We have reviewed the documentation for the
> use of Connection.Schema.ApplyFile() as it pertains to MobileVB. We can
> successfully monitor the OnSchemaUpgradeState
Change and
> OnSchemaUpgradeProge
ss events.
>
> Our problem is we cannot get a ULSchemaUpgradeState
of ulUpgradeStateDone,
> i.e. integer value 3. We go from 0 to 1 and then (after about 30-35
seconds)
> we go to ulUpgradeStateError,
i.e. integer value 4.
>
> We get this state (ulUpgradeStateError
) even when we try to apply the .usm
> which was used to
> create the .udb back onto the .udb. The documentation indicates this
action
> should be ignored by the call to ApplyFile if the .usm has already been
> applied.
>
> To add to (my) the confusion, if we take the .usm used to create the .udb,
> add a column to a table (or two) and create a new .usm, ApplyFile that new
> .usm to the original .udb, the database is actually updated successfully.
> The columns we added to the schema and applied to the database are
> successfully created by the ApplyFile call.
>
> My main questions / observations: What am I missing? It appears to work,
but
> how do I program to check for errors? Is there anything else I can monitor
> or check re: the process of applying the upgrade and related errors?
>
>
> ====================
====================
=
> Other Questions re: use of ApplyFile and .usm's post upgrade:
> ====================
====================
=
>
> 1.) I could not get the ApplyFile to execute until I actually disconnected
> and reconnected the database. I am guessing this is a function of my code
> and desire to "check a few thinks" before the upgrade rather than a
> functional requirement for the call? Is it a requirement to disconnect
from
> the database and reconnect if you perform any database operations prior to
> performing the ApplyFile?
>
> 2.) If our current database and schema are 1.udb/1.usm and our new schema
is
> 2.usm, after we call ApplyFile with 2.usm specified for application to the
> current connection, have both 1.udb and 1.usm been upgraded? or only
1.udb?
> We would use 2.usm to create the .udb in new deployments, but when
> specifying the connection parameters for the upgraded 1.udb (post
> application of 2.usm), must the 2.usm be specified in the connection or
will
> both 1.usm and 2.usm work?
>
> Thanks,
> Carl
>
>
>
>
>
>
>
>

Carl Langren

2006-02-09, 9:23 am

Mike,

Thanks very much for the response.

RE: item 2:
I now understand re: the use of .usm, that makes complete sense. Thanks.

RE: sqlcode question and item 1:
On the ApplyFile / "something left open" you were exactly correct. We were
getting a -214 (Table_open) which led us to one preparedstatement I missed.
Resolving that issue led to the following: When we apply the .usm, we get
a -953, SQLE_DATABASE_UPGRAD
E_NOT_ALLOWED, and the upgrade status makes it
from 0 to 2.

Does this have to do with our OEM version and connection_authentic
ation at
the ASA level? We construct our schema files (.usm) from an ASA reference
database which requires connection_authentic
ation. If that is the cause,
what is our course of action to facilitate in-place db upgrades at the
UltraLite clients?

Thanks for the assistance.

Sincerely,
Carl

===================
From previous reply:
===================[
color=darkred]
> What is the sqlcode after you get the failures?
>
> 1. Most likely you have something left open when you call ApplyFile().
> This is probably why disconnecting and reconnecting fixes the issue as it
> forces everything to close. No table, schema, preparedstatement or
> resultset objects can be open when ApplyFile() is called.
>
> 2. .usm files are only used to create databases. If the database already
> exists than any .usm parameter in the connection string will be ignored.
> The schema is loaded into the udb file when the db is created or ApplyFile
> is used. After an upgrade you can delete the .usm if you wish.
>
> Mike[/color]

Michael Thode

2006-02-09, 11:23 am

connection_authentic
ation at the ASA level won't affect ultralite in any
way.

That error will be raise in one of the following cases

- You have uncommitted rows in the DB
- You have a schema object open

What I'd suggest is to call apply file as the very first operation in your
code, then one by one add your code back in till you get the -953 error.
Hopefully that will allow you to narrow down the offending line of code.

Hope that helps
Mike

"Carl Langren" < clangren_nospam@worl
dnet.att.net> wrote in message
news:43eb4ff1$1@foru
ms-2-dub...
> Mike,
>
> Thanks very much for the response.
>
> RE: item 2:
> I now understand re: the use of .usm, that makes complete sense.
Thanks.
>
> RE: sqlcode question and item 1:
> On the ApplyFile / "something left open" you were exactly correct. We
were
> getting a -214 (Table_open) which led us to one preparedstatement I
missed.
> Resolving that issue led to the following: When we apply the .usm, we
get
> a -953, SQLE_DATABASE_UPGRAD
E_NOT_ALLOWED, and the upgrade status makes it
> from 0 to 2.
>
> Does this have to do with our OEM version and connection_authentic
ation at
> the ASA level? We construct our schema files (.usm) from an ASA reference
> database which requires connection_authentic
ation. If that is the cause,
> what is our course of action to facilitate in-place db upgrades at the
> UltraLite clients?
>
> Thanks for the assistance.
>
> Sincerely,
> Carl
>
> ===================
> From previous reply:
> ===================
it[color=darkred]
already[color=darkre
d]
ApplyFile[color=dark
red]
>
>

Carl Langren

2006-02-10, 1:23 pm

Dear Mike,

Thanks very much for the response.

I have pursued your suggestion re: tracking down the offending line of code
and my conclusion follow.
There were many intervening lines of code, but the exercise was fruitful.
My findings on our error are highly replicable, but not very rational,at
least to me..anyway....here they are.
------------------------------------------------------
When our code is:

ultblDiseasePS = ConnPIDS.PrepareStatement("SELECT Disease_code,
Description, dbstatus FROM tblDisease WHERE dbstatus <> 'D' and dbstatus <>
'R' ORDER by tblDisease.Disease_code ASC")
ultblDiseasePS.Close()
ultblDiseasePS = Nothing

ConnPIDS.Commit()
dbconn.Schema.ApplyFile(" schema_file=PIDSulPP
C_v1020000.usm")

> This code runs to completion without error.

-------------------------------------------------------
When our code is:
(Run from exactly the same place in code flow, just one more prepared
statement; actually the second one)

ultblDiseasePS = ConnPIDS.PrepareStatement("SELECT Disease_code,
Description, dbstatus FROM tblDisease WHERE dbstatus <> 'D' and dbstatus <>
'R' ORDER by tblDisease.Disease_code ASC")
ultblContactPS = ConnPIDS.PrepareStatement("SELECT Contact_ID,
rtrim(Last_name)+ ', ' + rtrim(First_name) + ' ' + rtrim(Middle_initial
) as
fullname, dbstatus FROM tblContact WHERE tblContact.Contact_ID > 100000 and
tblContact.Prescriber = 'Y' and dbstatus <> 'D' and dbstatus <> 'R' ORDER BY
tblContact.Last_name ASC") <<also tried order by fullname
ultblDiseasePS.Close()
ultblContactPS.Close()
ultblDiseasePS = Nothing
ultblContactPS = Nothing

ConnPIDS.Commit()
dbconn.Schema.ApplyFile(" schema_file=PIDSulPP
C_v1020000.usm")

> This code fails to run.
> This returns an error code of 91, Object reference not set to an
instance of an object.
Other comments: It also leaves a lock file open on the .udb after code
runs to completion; the lock file can be manually deleted without shutting
down the IDE; i.e. does not appear to be in use by any active process; the
lock file does not close when the IDE is closed; if we try to rerun the code
after deleting the .~db lock file we then get
SQLE_DATABASE_UPGRAD
E_NOT_POSSIBLE; likewise you cannot open the .udb with
UltraLite Interactive SQL, even after the ~db lock file has been deleted. In
other works, its a good 'ol corrupt udb.

-------------------------------------------------------
When our code is: (add one more prepared statement, and comment out the
second one that generated the error)

ultblDiseasePS = ConnPIDS.PrepareStatement("SELECT Disease_code,
Description, dbstatus FROM tblDisease WHERE dbstatus <> 'D' and dbstatus <>
'R' ORDER by tblDisease.Disease_code ASC")
'ultblContactPS = ConnPIDS.PrepareStatement("SELECT Contact_ID,
rtrim(Last_name)+ ', ' + rtrim(First_name) + ' ' + rtrim(Middle_initial
) as
fullname, dbstatus FROM tblContact WHERE tblContact.Contact_ID > 100000 and
tblContact.Prescriber = 'Y' and dbstatus <> 'D' and dbstatus <> 'R' ORDER BY
tblContact.Last_name ASC") <<also tried order by fullname
ultblDrugPS = ConnPIDS.PrepareStatement("SELECT Drug_code, Description,
dbstatus FROM tblDrug WHERE dbstatus <> 'D' and dbstatus <> 'R' ORDER by
tblDrug.Drug_code ASC")

ultblDiseasePS.Close()
'ultblContactPS.Close()
ultblDrugPS.Close()

ultblDiseasePS = Nothing
'ultblContactPS = Nothing
ultblDrugPS = Nothing

ConnPIDS.Commit()
dbconn.Schema.ApplyFile(" schema_file=PIDSulPP
C_v1020000.usm")

> This code runs to completion.

----------------------------------------------------------
When our code is: (put the failing prepared statement back in BUT remove the
entire order by statement OR do an order by something other than Last_name
or fullname) (I also tried changing other elements of the query, remove the
constructed fullname, remove the where, a bunch of stuff....but the only
thing that seemed causal was the order by on Last_name or fullname.
Last_name is not a key or index, and no part of fullname is a key or index.
Order by 'worked' as long as it wasn't on fullname or Last_name.)

ultblDiseasePS = ConnPIDS.PrepareStatement("SELECT Disease_code,
Description, dbstatus FROM tblDisease WHERE dbstatus <> 'D' and dbstatus <>
'R' ORDER by tblDisease.Disease_code ASC")
ultblContactPS = ConnPIDS.PrepareStatement("SELECT Contact_ID,
rtrim(Last_name)+ ', ' + rtrim(First_name) + ' ' + rtrim(Middle_initial
) as
fullname, dbstatus FROM tblContact WHERE tblContact.Contact_ID > 100000 and
tblContact.Prescriber = 'Y' and dbstatus <> 'D' and dbstatus <> 'R'")
ultblContactPS = ConnPIDS.PrepareStatement("SELECT Contact_ID FROM
tblContact")
ultblDrugPS = ConnPIDS.PrepareStatement("SELECT Drug_code, Description,
dbstatus FROM tblDrug WHERE dbstatus <> 'D' and dbstatus <> 'R' ORDER by
tblDrug.Drug_code ASC")

ultblDiseasePS.Close()
ultblContactPS.Close()
ultblDrugPS.Close()

ultblDiseasePS = Nothing
ultblContactPS = Nothing
ultblDrugPS = Nothing

ConnPIDS.Commit()
dbconn.Schema.ApplyFile(" schema_file=PIDSulPP
C_v1020000.usm")

> This code runs to completion.

----------------------------------------------------------
In conclusion:

Even though the prepared statement is closed and set to nothing, the syntax
of query impacts the success of ApplyFile() on the new schema. It didn't
make sense to me, but it replicates like a banshee. I presume I will have to
change my query and go from there. I don't want to confess how many runs it
took me to get this narrowed down.......

Any other input would be most welcome.

Thanks and have a great weekend,
Carl

"Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
news:43eb7651$1@foru
ms-1-dub...
> connection_authentic
ation at the ASA level won't affect ultralite in any
> way.
>
> That error will be raise in one of the following cases
>
> - You have uncommitted rows in the DB
> - You have a schema object open
>
> What I'd suggest is to call apply file as the very first operation in your
> code, then one by one add your code back in till you get the -953 error.
> Hopefully that will allow you to narrow down the offending line of code.
>
> Hope that helps
> Mike

Michael Thode

2006-02-14, 8:24 pm

Thanks for narrowing down the problem, that helps a lot. We'll take a look
at the files you've sent.

Mike

"Carl Langren" < clangren_nospam@worl
dnet.att.net> wrote in message
news:43efd681@forums
-1-dub...
> Mike,
>
> I have advanced the ball a bit since my post on Friday.
>
> I am using the iAnywhere. UltraLiteForAppForge
.dll to manipulate an
> UltraLite database at the desktop. Monday I will move on to the PDA and
see
> if the same conditions occur there as do in the IDE. Those conditions are
> basically that the UltraLiteAFLib. ULSchemaUpgradeState
never gets to
> ulUpgradeStateDone (or integer of 3) when an ApplyFile is run against an
> existing UltraLite database. I have stripped down the code, schemas and
> database to a very minimal state for documenting this condition. I also
> added code to send a bit of information to the debugging interface so it's
> (hopefully) easier to see what's going on. I also added a MsgBox which
> throws the ulUpgradeState to a window.
>
> Attached to this post is a vb.net project which does the following:
>
> 1. Builds an UltraLite connection.
> 2. Creates an UltraLite database from the PPC.usm schema using the
> connection from step 1. This schema has less than 10 tables.
> 3. Disconnects from the PPC.udb which was created in step 2.
> 4. Builds a second UltraLite connection. This connection is created
> WithEvents so we see the progresion of the
> UltraLiteAFLib. ULSchemaUpgradeState
.
> 5. Makes a call to Schema.ApplyFile to apply the PPC_Revised.usm to the
> PPC.udb UltraLite database created in step 2. This schema has exactly one
> more table (named OneMoreTable) than PPC.usm and that table has only 4
> elements.
> 6. Provides feedback about that upgrade process in the debugging window
and
> to the screen.
> 7. That's it.
>
> (I didn't delete the created PPC.udb via code, so if you run the app more
> than once, you will need to delete the PPC.udb from the \bin directory.
> Also, note both .usm files need to be in the \bin directory for the app to
> run.)
>
> When you run this application you will (hopefully) see that the
> ULSchemaUpgradeState
goes from:
>
> Further, when you apply the same exact schema to the database after it was
> just created using that schema, the ULSchemaUpgradeState
goes from 0 to 4.
>
> By the way, the ApplyFile does in fact upgrade the database correctly and
it
> is accessible after the upgrade. In the FYI category, the db is bigger
when
> you create from PPC.usm and ApplyFile from PPC_Revised.usm than if you
just
> build it with PPC_Revised.usm.
>
> I am trying to implement an upgrade to our deployed application, but
cannot
> see how to monitor for ULSchemaUpgradeState
getting to Done (or 3) as it
> never gets there.
>
> Your assistance is most appreciated.
>
> Regards,
> Carl
>
>
>

Chris Retterath

2006-02-15, 9:24 am

<<I tried emailing you directly but your email doesn't work, btw>>

I'm looking at this issue and I am a little bit confused by your last email.
Your provide an app on the desktop that uses ApplyFile to update the
schema -- I tried it on my machine
and it seems to work fine. And it appears it works for you as well.

So the issue is back to where you have an ApplyFile that fails if you run it
after preparing
two statements (without ever getting result sets back, btw).

The AppyFile() fails with a non-recoverable error (that's why you are seeing
a corrupt database and a .~db file dropping)
However your last email seems to imply that things are working..

Any guidance would be appreciated,

Chris Retterath, iAnywhere Solutions

"Carl Langren" < clangren_nospam@worl
dnet.att.net> wrote in message
news:43efd681@forums
-1-dub...
> Mike,
>
> I have advanced the ball a bit since my post on Friday.
>
> I am using the iAnywhere. UltraLiteForAppForge
.dll to manipulate an
> UltraLite database at the desktop. Monday I will move on to the PDA and
> see if the same conditions occur there as do in the IDE. Those conditions
> are basically that the UltraLiteAFLib. ULSchemaUpgradeState
never gets to
> ulUpgradeStateDone (or integer of 3) when an ApplyFile is run against an
> existing UltraLite database. I have stripped down the code, schemas and
> database to a very minimal state for documenting this condition. I also
> added code to send a bit of information to the debugging interface so it's
> (hopefully) easier to see what's going on. I also added a MsgBox which
> throws the ulUpgradeState to a window.
>
> Attached to this post is a vb.net project which does the following:
>
> 1. Builds an UltraLite connection.
> 2. Creates an UltraLite database from the PPC.usm schema using the
> connection from step 1. This schema has less than 10 tables.
> 3. Disconnects from the PPC.udb which was created in step 2.
> 4. Builds a second UltraLite connection. This connection is created
> WithEvents so we see the progresion of the
> UltraLiteAFLib. ULSchemaUpgradeState
.
> 5. Makes a call to Schema.ApplyFile to apply the PPC_Revised.usm to the
> PPC.udb UltraLite database created in step 2. This schema has exactly one
> more table (named OneMoreTable) than PPC.usm and that table has only 4
> elements.
> 6. Provides feedback about that upgrade process in the debugging window
> and to the screen.
> 7. That's it.
>
> (I didn't delete the created PPC.udb via code, so if you run the app more
> than once, you will need to delete the PPC.udb from the \bin directory.
> Also, note both .usm files need to be in the \bin directory for the app to
> run.)
>
> When you run this application you will (hopefully) see that the
> ULSchemaUpgradeState
goes from:
>
> Further, when you apply the same exact schema to the database after it was
> just created using that schema, the ULSchemaUpgradeState
goes from 0 to 4.
>
> By the way, the ApplyFile does in fact upgrade the database correctly and
> it is accessible after the upgrade. In the FYI category, the db is bigger
> when you create from PPC.usm and ApplyFile from PPC_Revised.usm than if
> you just build it with PPC_Revised.usm.
>
> I am trying to implement an upgrade to our deployed application, but
> cannot see how to monitor for ULSchemaUpgradeState
getting to Done (or 3)
> as it never gets there.
>
> Your assistance is most appreciated.
>
> Regards,
> Carl
>
>

Carl Langren

2006-02-15, 8:23 pm

Dear Chris,

Thanks for the reponse.
You should be able to get me directly at the clangren at worldnet dot att
dot net address.

The issue I am trying to focus on is the ULSchemaUpgradeState
never goes to
Done / int value 3.
In the packaged example, the ULSchemaUpgradeState
goes from 0 to 1 to 4. The
state of 4 means Error.

My issue is "How do I know it worked?" when testing for the state after the
ApplyFile runs.
Based on a return value of Error/4 I would conclude it blew up.
However, when you look at the db using uisql (which is not practical in the
deployed environment) the changes were applied.

I was seeing some corruption, but am not seeing corruption in this packaged
example.
I figured first things first: get any example (small # tables) to go to
state Done before trying to do our real db (100+ tables).

My focus now is to get any ApplyFile to go to state Done, which I have not
been able to do in our environment.

Thanks for your assistance.

Sincerely,
Carl

"Chris Retterath" <Chris.Retterath@sybase.com> wrote in message
news:43f342be$1@foru
ms-1-dub...
> <<I tried emailing you directly but your email doesn't work, btw>>
>
> I'm looking at this issue and I am a little bit confused by your last
> email.
> Your provide an app on the desktop that uses ApplyFile to update the
> schema -- I tried it on my machine
> and it seems to work fine. And it appears it works for you as well.
>
> So the issue is back to where you have an ApplyFile that fails if you run
> it after preparing
> two statements (without ever getting result sets back, btw).
>
> The AppyFile() fails with a non-recoverable error (that's why you are
> seeing a corrupt database and a .~db file dropping)
> However your last email seems to imply that things are working..
>
> Any guidance would be appreciated,
>
> Chris Retterath, iAnywhere Solutions
>
> "Carl Langren" < clangren_nospam@worl
dnet.att.net> wrote in message
> news:43efd681@forums
-1-dub...
>
>

Chris Retterath

2006-02-16, 11:23 am

Thanks for your prodding -- looking at the actual state codes we have found
they were encoded incorrectly.

The enumeration values provided in the AppForge UltraLite component are as
follows:
<element name=" ulUpgradeStateStarti
ng" value="0"/>
<element name=" ulUpgradeStateUpgrad
ing" value="1"/>
<element name="ulUpgradeStateAbort" value="2"/>
<element name="ulUpgradeStateDone" value="3"/>
<element name="ulUpgradeStateError" value="4"/>

The actual correct state values (from the underlying state change code) are
actually as follows:
UL_UPGRADE_STATE_STA
RTING = 0, // Begining upgrade, can safely abort at this
point
UL_UPGRADE_STATE_UPG
RADING = 1, // The upgrade is in progress
UL_UPGRADE_STATE_ABO
RT = 2, // Schema upgrade aborted, the old database is
preserved
UL_UPGRADE_STATE_ERR
OR = 3, // A critial error occured, the database is
unusable
UL_UPGRADE_STATE_DON
E =4 // The upgrade completed successfully

The enumeration in AppForge is wrong in that ulUpgradeStateDone should have
value 4 (not 3),
and the value of ulUpgradeStateError should be 3 (not 4).

So you should expect to see the states 0, 1, 4 on a successful ApplyFile().
You would only see states 2 or 3
on an error, with 2 for a recoverable error and 3 for an unrecoverable
(corrupt database) error.

Suggest you define your own constants for now:
myUpgradeStateError = 3

myUpgradeStateDone = 4

and we will get this fixed in the next EBF round.

Chris Retterath, iAnywhere Solutions

"Carl Langren" < clangren_nospam@worl
dnet.att.net> wrote in message
news:43f39b7d$1@foru
ms-2-dub...[color=darkred]
> Dear Chris,
>
> Thanks for the reponse.
> You should be able to get me directly at the clangren at worldnet dot att
> dot net address.
>
> The issue I am trying to focus on is the ULSchemaUpgradeState
never goes
> to Done / int value 3.
> In the packaged example, the ULSchemaUpgradeState
goes from 0 to 1 to 4.
> The state of 4 means Error.
>
> My issue is "How do I know it worked?" when testing for the state after
> the ApplyFile runs.
> Based on a return value of Error/4 I would conclude it blew up.
> However, when you look at the db using uisql (which is not practical in
> the deployed environment) the changes were applied.
>
> I was seeing some corruption, but am not seeing corruption in this
> packaged example.
> I figured first things first: get any example (small # tables) to go to
> state Done before trying to do our real db (100+ tables).
>
> My focus now is to get any ApplyFile to go to state Done, which I have not
> been able to do in our environment.
>
> Thanks for your assistance.
>
> Sincerely,
> Carl
>
>
> "Chris Retterath" <Chris.Retterath@sybase.com> wrote in message
> news:43f342be$1@foru
ms-1-dub...

Carl Langren

2006-02-18, 7:23 am

Dear Chris,

Excellent, and thanks very much for the assistance!

Regards,
Carl

"Chris Retterath" <Chris.Retterath@sybase.com> wrote in message
news:43f4ab4b$1@foru
ms-2-dub...
> Thanks for your prodding -- looking at the actual state codes we have
> found they were encoded incorrectly.
>
> The enumeration values provided in the AppForge UltraLite component are as
> follows:
> <element name=" ulUpgradeStateStarti
ng" value="0"/>
> <element name=" ulUpgradeStateUpgrad
ing" value="1"/>
> <element name="ulUpgradeStateAbort" value="2"/>
> <element name="ulUpgradeStateDone" value="3"/>
> <element name="ulUpgradeStateError" value="4"/>
>
> The actual correct state values (from the underlying state change code)
> are actually as follows:
> UL_UPGRADE_STATE_STA
RTING = 0, // Begining upgrade, can safely abort at
> this point
> UL_UPGRADE_STATE_UPG
RADING = 1, // The upgrade is in progress
> UL_UPGRADE_STATE_ABO
RT = 2, // Schema upgrade aborted, the old database is
> preserved
> UL_UPGRADE_STATE_ERR
OR = 3, // A critial error occured, the database is
> unusable
> UL_UPGRADE_STATE_DON
E =4 // The upgrade completed successfully
>
> The enumeration in AppForge is wrong in that ulUpgradeStateDone should
> have value 4 (not 3),
> and the value of ulUpgradeStateError should be 3 (not 4).
>
> So you should expect to see the states 0, 1, 4 on a successful
> ApplyFile(). You would only see states 2 or 3
> on an error, with 2 for a recoverable error and 3 for an unrecoverable
> (corrupt database) error.
>
> Suggest you define your own constants for now:
> myUpgradeStateError = 3
>
> myUpgradeStateDone = 4
>
> and we will get this fixed in the next EBF round.
>
> Chris Retterath, iAnywhere Solutions

Sponsored Links