After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Bryce:

No, the TABLE_SIZE parameter only controls the default sizing for new tables at create time. It has no effect beyond that.

Here, I compiled my sqlstruct utility with CSDK 4.50 running against v15.0.1.0.3 in infrastructure v1:

Works just fine.

Art

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Thanks first to Art for pointing out this oversight on my part!

Regarding Bryce's comments, I think there are two points still to make:

• tables newly created by pre-v15 clients will automatically become SMALL tables, regardless of TABLE_SIZE - this likely explains his experience in this regard.
• sequences, on their face, behave the same: no problem when created by old clients, yet producing odd errors indeed when created by v15 client and then used (or dropped) by old ones.

This latter problem, afaics, hadn't been brought to our attention yet, but should be fixed easily (why would a sequence have to be "LARGE"?)

 Andreas

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Andreas:

Very strange. Testing sequences with both v15 and v4.50 CSDK compiles. Using a v4.50 compiled version of Jonathan's sqlcmd: in one database sequences return an error:

SQL[10]: select yas.nextval;
SQL -242: Could not open database table (art.yas).
ISAM -21569: <<error message text not found>>
SQLSTATE: IX000 at /dev/stdin:1

In another it works just fine:

Thanks first to Art for pointing out this oversight on my part!

Regarding Bryce's comments, I think there are two points still to make:

• tables newly created by pre-v15 clients will automatically become SMALL tables, regardless of TABLE_SIZE - this likely explains his experience in this regard.
• sequences, on their face, behave the same: no problem when created by old clients, yet producing odd errors indeed when created by v15 client and then used (or dropped) by old ones.

This latter problem, afaics, hadn't been brought to our attention yet, but should be fixed easily (why would a sequence have to be "LARGE"?)

 Andreas

Thanks Andreas and Art.

I have set the TABLE_SIZE to SMALL in onconfig. Am I correct to assume that 4.50 clients will continue to work without issues against 15 (in normal mode) as long as all tables remain SMALL?

Best regards,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Art.

If I change mode to native mode, all the tables will have the new limits?

Thanks.

Luis

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Art.

If I change mode to native mode, all the tables will have the new limits?

Thanks.

Luis

Andreas:

You said " the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from". There is one other, you do not have to recode and recompile existing code required by the change in the changes to the sqlca structure. For some that is going to be a tough nut due to lost source or 3rd party software.

Art

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S

We have currently a case open (TS021681890), where reverting from 15.0.1 did not work due to very first root-chunk only having 3000 pages and the second root-chunk has 5000 pages. And we needed to add a third root-chunk for Informix 15 Migration. However, this is an instance which has grown over years. But this might be the case in many installations as not everywhere there is the possibility to dbexport & dbimport to consolidate root-chunks, etc.

Let me cite support: When there are chunk extended reserved pages that are not in chunk 1, the server only used the page offset, and assumed that is in chunk 1. Thus giving a warning of I/O bad request with page offset greater than the number of pages in chunk 1. This issue affects all reversion from 15.0.1 to any previous versions.

The consequences were dire in our test. The DB did not come up in Informix 14 nor in Informix 15.

Support told me that the case is already marked as a must fix for 15.0.1.6.

Might be no problem if you have only one root-chunk. However, if you think you need the possibility to revert, i would test it prior to migration.

Hi Snorri,

I think you correctly spotted it: you're not going to take advantage of the new 8-byte timestamps, with consequences for incremental backups.

So the only "advantage" of, in fact the only reason to remain in "compatibility mode" is the ability to revert to where you came from (12.10 or 14.10).

BR,
 Andreas

After upgrading from 14 to 15 the server is in Compatibility mode. If there is no plan to use larger tables, chunks, and page sizes would it be OK just to keep it in  Compatibility mode indefinitely? Or are there some other 15 features missing in this mode, like will we still be seeing " WARNING: Next backup of DBspace rootdbs must be level-0 backup"?

Thanks in advance,

-S