arghhh 64 bit Access oledb struggle

[m.posseth]

To all ,,,

with VS.Net 2005 you can not access a Access database when this runs on a
64 bit system ( when compiled in CPU type anny or X64 )

i feel that MS should include a 64 bit Oledb driver , maybe if a lot of us
complain about this missing driver we encourage them to create one

http://lab.msdn.microsoft.com/productfeedback/
No i can not switch to SQL Express and yes i know i can avoid this problem
by compiling to x86 mode and so forcing the framework into WOW modus
however i would like it if i could deploy my app in anny cpu type modus (
for the rest it runs perfect on 64 bit systems )

Also tried to put the Access stuff in a seperate assembly but it is not
getting fooled by this, the program will then not even start , so the only
scenario i can think of is creating a remoting component (thus a app that
handles the db traffic and marshall the data to the 64 bit app ) but this
will give so much overhead that i could better run my complete proggy 32 bit
Really wish there was a good alternative for Access but there isn`t ,,,,,,
( if you want to deploy your data secured , with a small footprint , that
also runs on win 9.x )
regards

Michel Posseth [MCP]

[Ken Tucker [MVP]]

Hi,

I agree with you. There should either be 64 bit odbc drivers or
the classes should automatically use the 32 bit ones. I submitted this
suggestion a while ago.

http://lab.msdn.microsoft.com/produc...0-d25b58ce8ae8

Ken Tucker
--------------------

"m.posseth" wrote:

To all ,,,

with VS.Net 2005 you can not access a Access database when this runs on a
64 bit system ( when compiled in CPU type anny or X64 )

i feel that MS should include a 64 bit Oledb driver , maybe if a lot of us
complain about this missing driver we encourage them to create one

http://lab.msdn.microsoft.com/productfeedback/
No i can not switch to SQL Express and yes i know i can avoid this problem
by compiling to x86 mode and so forcing the framework into WOW modus
however i would like it if i could deploy my app in anny cpu type modus (
for the rest it runs perfect on 64 bit systems )

Also tried to put the Access stuff in a seperate assembly but it is not
getting fooled by this, the program will then not even start , so the only
scenario i can think of is creating a remoting component (thus a app that
handles the db traffic and marshall the data to the 64 bit app ) but this
will give so much overhead that i could better run my complete proggy 32 bit
Really wish there was a good alternative for Access but there isn`t ,,,,,,
( if you want to deploy your data secured , with a small footprint , that
also runs on win 9.x )
regards

Michel Posseth [MCP]

[m.posseth]

Well i feel that more people should raise there voice and make MS clear that
this is a verry important issue for a good and quick migration path to
programs that can be compiled with the anny CPU option on ( wich is my
goal ) however as long as other developers do not see the need of the 64 bit
platform i guess we are allone in the dessert ... :-(

i hope we wake same of them up in time before it is to late .......
regards

Michel Posseth


"Ken Tucker [MVP]" <Ke**********@discussions.microsoft.com> wrote in message
news:4D**********************************@microsof t.com...

Hi,

I agree with you. There should either be 64 bit odbc drivers or
the classes should automatically use the 32 bit ones. I submitted this
suggestion a while ago.

http://lab.msdn.microsoft.com/produc...0-d25b58ce8ae8

Ken Tucker
--------------------

"m.posseth" wrote:

To all ,,,

with VS.Net 2005 you can not access a Access database when this runs on
a
64 bit system ( when compiled in CPU type anny or X64 )

i feel that MS should include a 64 bit Oledb driver , maybe if a lot of
us
complain about this missing driver we encourage them to create one

http://lab.msdn.microsoft.com/productfeedback/
No i can not switch to SQL Express and yes i know i can avoid this
problem
by compiling to x86 mode and so forcing the framework into WOW modus
however i would like it if i could deploy my app in anny cpu type modus
(
for the rest it runs perfect on 64 bit systems )

Also tried to put the Access stuff in a seperate assembly but it is not
getting fooled by this, the program will then not even start , so the
only
scenario i can think of is creating a remoting component (thus a app that
handles the db traffic and marshall the data to the 64 bit app ) but this
will give so much overhead that i could better run my complete proggy 32
bit
Really wish there was a good alternative for Access but there isn`t
,,,,,,
( if you want to deploy your data secured , with a small footprint ,
that
also runs on win 9.x )
regards

Michel Posseth [MCP]

[m.posseth]

after some thinking ,, and as i feel that this is a verry important issume
for me and future people who want to write 64 bit compatible programs , i
decided to sent Steve B an e-mail regarding this , i wonder what the
reponse will be :-)

Met him once at a conference where he said that we ( developers ) could
always send him an e-mail , well i believe he is a man of his words

regards

Michel Posseth

"Ken Tucker [MVP]" <Ke**********@discussions.microsoft.com> wrote in message
news:4D**********************************@microsof t.com...

Hi,

I agree with you. There should either be 64 bit odbc drivers or
the classes should automatically use the 32 bit ones. I submitted this
suggestion a while ago.

http://lab.msdn.microsoft.com/produc...0-d25b58ce8ae8

Ken Tucker
--------------------

"m.posseth" wrote:

To all ,,,

with VS.Net 2005 you can not access a Access database when this runs on
a
64 bit system ( when compiled in CPU type anny or X64 )

i feel that MS should include a 64 bit Oledb driver , maybe if a lot of
us
complain about this missing driver we encourage them to create one

http://lab.msdn.microsoft.com/productfeedback/
No i can not switch to SQL Express and yes i know i can avoid this
problem
by compiling to x86 mode and so forcing the framework into WOW modus
however i would like it if i could deploy my app in anny cpu type modus
(
for the rest it runs perfect on 64 bit systems )

Also tried to put the Access stuff in a seperate assembly but it is not
getting fooled by this, the program will then not even start , so the
only
scenario i can think of is creating a remoting component (thus a app that
handles the db traffic and marshall the data to the 64 bit app ) but this
will give so much overhead that i could better run my complete proggy 32
bit
Really wish there was a good alternative for Access but there isn`t
,,,,,,
( if you want to deploy your data secured , with a small footprint ,
that
also runs on win 9.x )
regards

Michel Posseth [MCP]