db COnversion

[R. Paulson]

Hi I have an overgrown Access APP.
I want to put it in a 64 bit environment but I need to convert it to
something, I need help on this, what is the easiest route and tools for
either SQL or VB.NET there seems a lot of syntax to be changed and far from
hiring a team of programmers I would like to know if there is a shortcut.

Thanks.

[Cor Ligthert]

R Paulson,

I would not take to much expectations from the idea of performance benefits
by upgrading to a 64Bits environment. (In VBNet the Integer stays even
32Bits and would therefore need probably slightly more processing than now,
although the new 64Bits processors have a higher cycle times so that will
probably not be recognized)

As mostly with Microsoft software will the current software run on the next
OS version.

However going from Access to SQL server will probably give you benefit as
well as better maintenance in future with creating programs OOP and more
posibilities to get the bottle necks from your programs and optimize it for
your need.

However as I have seen in this newsgroups is there not an easier tool for
it, than hiring some developpers. Set your current programs in whatever
structured description format and start programming again.

You can as well think about using Access on your SQL server by the way.

However as mostly with Access have you as well a maintenance problem and are
you now not able to optimize it.

I hope this gives some idea's,

Cor

[Jay B. Harlow [MVP - Outlook]]

Cor,
Some actual information on the performance of 32bit integers on 64bit
platforms.

http://blogs.msdn.com/joshwil/archiv...28/413320.aspx
As well as 64bit integers on 32bit platforms.

Of course with Josh's specific example I would use Buffer.BlockCopy &
probably not worry about the performance...

Hope this helps
Jay

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
|R Paulson,
|
| I would not take to much expectations from the idea of performance
benefits
| by upgrading to a 64Bits environment. (In VBNet the Integer stays even
| 32Bits and would therefore need probably slightly more processing than
now,
| although the new 64Bits processors have a higher cycle times so that will
| probably not be recognized)
|
| As mostly with Microsoft software will the current software run on the
next
| OS version.
|
| However going from Access to SQL server will probably give you benefit as
| well as better maintenance in future with creating programs OOP and more
| posibilities to get the bottle necks from your programs and optimize it
for
| your need.
|
| However as I have seen in this newsgroups is there not an easier tool for
| it, than hiring some developpers. Set your current programs in whatever
| structured description format and start programming again.
|
| You can as well think about using Access on your SQL server by the way.
|
| However as mostly with Access have you as well a maintenance problem and
are
| you now not able to optimize it.
|
| I hope this gives some idea's,
|
| Cor
|
|

[Jay B. Harlow [MVP - Outlook]]

Cor,
FWIW: A couple more interesting "real life" links on the performance of
64bit Windows XP.

http://www.microsoft.com/windowsxp/u...loringx64.mspx

Specifically:
http://www.cakewalk.com/x64/whitepaper.asp

Unfortunately my app uses Interop so testing it under 64bit is not an option
right now. However I am looking at moving the Interop piece to be a
replacable plug in, allowing the 64bit to use something other then Interop.
My app is primarily text (XML) processing so 32-bit vs 64-Bit Integer size
is imaterial. I would expect a slight increase in performance under 64bit
due to the greater number of registers (the JIT is able to enregister more
variables) and the increased amount of memory (less disk swapping). However
my app may be IO bound...

Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
|R Paulson,
|
| I would not take to much expectations from the idea of performance
benefits
| by upgrading to a 64Bits environment. (In VBNet the Integer stays even
| 32Bits and would therefore need probably slightly more processing than
now,
| although the new 64Bits processors have a higher cycle times so that will
| probably not be recognized)
|
| As mostly with Microsoft software will the current software run on the
next
| OS version.
|
| However going from Access to SQL server will probably give you benefit as
| well as better maintenance in future with creating programs OOP and more
| posibilities to get the bottle necks from your programs and optimize it
for
| your need.
|
| However as I have seen in this newsgroups is there not an easier tool for
| it, than hiring some developpers. Set your current programs in whatever
| structured description format and start programming again.
|
| You can as well think about using Access on your SQL server by the way.
|
| However as mostly with Access have you as well a maintenance problem and
are
| you now not able to optimize it.
|
| I hope this gives some idea's,
|
| Cor
|
|

[Cor Ligthert]

Jay,

Thanks, both very interesting articles. I have seen in previous messages
from you about your use of pluggins and see in the second article your
problem.

When I think on the 80-20 rule, than are in my opinion in text processing
always things as replace and spellchecker bottleneck's. Maybe can you
benefit in that area from this new technology. However I agree with you that
when it is normal flat processing you will probably have no benefit, again
accoording to the 80-20 rule.

As first thought reading about WOW64, I had the idea "Windows95 is back
again" history repeats (DosOnW32). While there is of course probably learned
a lot from that.

Cor