Home » discuss » Public forums » iMIS Community

New Schema Points to Lots of Re-work Ahead

Posted August 30th, 2012 by Lynea
|

We will be likely upgrading within the next month or so to the latest and greatest 15.2.##, so in preparation, I reviewed the most recently published schema, 15.2.1, (http://www.imiscommunity.com/schema_for_15_2_1).   I couldn't help notice that most of the tables we use were dropped and reincarnated into views. That means I'll be converting tons and tons of scripts from tables to views, and also make updates to Business Objects, iQAs, iMIS Reporting, Crystal Report objects, etc., is that not correct?

Also, with this new version, we should be able to still import our currently existing customized views into the upgrade during the development stage, correct?

 

Thanks,

Lynea E. Bernhard

EPCOR

‹ Task Centre SMTPHow to change database collation ›
login or register to post comments | printer friendly version

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Probably not

On August 30th, 2012 Bruce Wilson says:

The conversion process should migrate the existing data to new tables before it creates the views, and the views should behave the same way as the tables you know and love.

Of course, your mileage may vary. This is one important reason to do a test upgrade so you can discover any changes in behavior.
--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP

login or register to post comments

Conversion Process...

On August 30th, 2012 Lynea says:

Yes, that makes sense:  The conversion process takes the existing data tables and brings them first into new tables to prepare them for their becoming views. 
However, this conversion process doesn't address all the customizations that have to be edited to call on the views that ultimately, dropped the old tables, right?  I mean, those tables that are recreated versions of the old tables that are being converted to views, are dropped during the conversion process after they are created into views, correct?

 

Lynea Bernhard

EPCOR

login or register to post comments

What tables are you using

On August 30th, 2012 Paul Bradshaw says:

What tables are you using that have been dropped and reincarnated into views?  Can you post more specifics about what concerns you?  And what version are you upgrading FROM?

login or register to post comments

SOME of the Tables that have changed that we use

On August 30th, 2012 Lynea says:

 These are the biggest ones: 

These two biggest changes for table drops for us would probably be the OrderMain and OrderLines.

 

Lynea Bernhard

EPCOR

 

login or register to post comments

Those tables were never used

On August 30th, 2012 Paul Bradshaw says:

Those tables were never used in iMIS 15.x, which is why they were dropped.

The correct tables to use are Orders and Order_Lines

 

 

login or register to post comments

Order_Lines vs. OrderLines

On August 30th, 2012 Lynea says:

Yes, I see I got them confused when I was just reading the schema.   Oddly enough, when I checked SQL Server, we actually have dependencies on each of those tables that weren't supposed to have been used.

 

Lynea Bernhard

EPCOR

 

 

login or register to post comments

One of the reasons these

On August 30th, 2012 Paul Bradshaw says:

One of the reasons these tables are being dropped is to avoid just this kind of confusion. 

 

login or register to post comments

Makes sense...

On August 30th, 2012 Lynea says:

So, do you suppose that those dependencies on those tables are probably nothing?

login or register to post comments

More details

On August 30th, 2012 Paul Bradshaw says:

Out of the box, there are a bunch of things that depend on those tables (views, functions, other tables).  All of those are being dropped together.

If there are any custom (non-out-of-the-box iMIS Tables, views, etc) dependencies, then those probably haven't been working "correctly" anyway.  You'll have to example your own custom tables, views, triggers, to ensure none of them have dependencies on these items, and if you find any, correct them to depend on the correct standard iMIS Tables.

As an example, objects that depend on OrderMain include

  • the function: "asi_FindOrderLine",
  • the tables: "OrderLIne, OrderShpTo, OrderTaxLine, Shipment and WorkTransactionMain,
  • and the views: vBoOrder, vGLTransReport, vOrderAllReport, vOrderReport, vPaymentApplicationSummary, vPaymentApplicationToOrder, vPickListreport, vPostingInvoiceData. 

ALL of these items are being dropped.  If you have any ADDITIONAL items that depend on OrderMain, then you'll need to clean those up before upgrading (either drop them entirely, or rework to point them at the correct tables).

Does that make sense?

You'll definitely want to run test upgrades, as Bruce advises, prior to doing any official upgrade.  If you don't have any custom stored procedures, tables, views, or functions that depend on the objects being dropped (and you shouldn't) then the upgrade should "just work".  If you DO have such dependencies, then upgrade will most likely fail, and you'll need to work to remove those dependencies in whichever way makes sense (drop them entirely because they're unused, or rework them to depend on the "correct" tables).

 

login or register to post comments