Recent content by gah

Hi requirement: to extract data into SQL 2008 R2 from OpenEdge 10.1C environment: Progress 10.1C 32bit running on Windows 2003 server (32bit) SQL 2008R2 64bit running on Windows 2008 server (64bit) ..long story short: can this be done via SQL SSMS using an OPENEDGE 10.2x 64bit ODBC...

Another issue with the D&L was that after we performed it we still had a scatter factor over 1.0....see results below as an example. We had followed the vendors supplied script which loaded tables in alphabetical name order....vendor now tells us that we need to reorder the load script to load...

Thanks for clearing up my misconception re load times. re type 2 areas ...what improvement in query response time could we expect from moving from type 1 to type 2 in the main 4GL Progress application? Vendor indicates maybe 10%.....but they have also said previously that they dont know if we...

Update... looking more closely at where the extract slows down...and is noticeable for all large tables...it would appear that this happens with records written after our previous dump and load. eg Table slows down at 1.28M recs, Table 2 at 3.5M recs etc...precisely the number of records...

These are the results for dbanalys.....as I am sure you will appreciate they dont mean a lot to me. I have only included the relevant results for the table that I am testing on. any thoughts on these results please? OpenEdge Release 10.1C03 as of Sun Feb 1 00:37:52 EST 2009 PROGRESS Database...

Tom many thanks for your responses...certainly food for thought here. Will be having a discussion with the vendor ASAP :)

the db was recently upgraded to 10.1C from 9.1E a month ago....onto a new server. I know that a dump and reload is probably required....but first off I will run dbanalys this evening and see what comes back. If the table that I am testing with requires idxbuild then I will do that and retest...

These are the results OpenEdge Release 10.1C03 as of Sun Feb 1 00:37:52 EST 2009 Area Name: Control Area, Type 6, Block Size 4096, Extents 1, Records/Block 32, Cluster Size 1 Ext # 1, Type VARIABLE, Size 32 KByte, Name: D:\ tst_data.db Area Name: Primary Recovery Area, Type 3, Block Size...

Not sure about the storage areas...how would I find out? We can run dbnanalys...can we do that on a single table or does is it have to be the full db (430 tables)? gah

Larry ,,thanks for your thoughts. have tried this a while back and as I recall; it made no difference ultimately I require all fields from this table...so this will not help the cause I am afraid. This problem is not specific to a single table either ....I have tested similar extracts on...

We have also resurrected our old 9.1E server and running same queries against same table...we do not experience any slow down in the extract at all. the only difference is Progress version and ODBC driver. regards gah

Have run "update statistics" from SQLExplorer CLI for INDEX/TABLE/COLUMNS on this particular table. Unfortunately this has not delivered any improvement at all to the extract time. A little more experimentation provide the following: SELECT COL_1 FROM PUB.MYTABLE WHERE COL_1 > 0 AND COL_1...

Hi Casper I will have another go with update stats WITH commit...if I can get this to run from my ODBC connection. I note your comments re the parameters...I had already read this and passed this back to the vendor. I am still in discussion with the vendor on how I can run SQLExplorer from...

Update I believe I have run update statistics... the only way I could get this to perform was by setting the DSN Advanced from READ_UNCOMMITTED to "blank" ...although the query ran I am not sure how to check success. The statement was UPDATE TABLE STATISTICS AND INDEX STATISTICS AND COLUMN...

..thanjs for this will review Squirrel and see how I get on. Kind regards