Вот интересно, у меня прога, которая читает данные из Access-овской базы. Я её специально переделывал, чтобы она в win98 работала с юникодом, а она мне пишет на файл, созданный в Access2k (который в win98 прекрасно работает), что он в неизвестном формате, а если в Access-е пересохранить базу в "предыдущую версию", то юникодовские символы (иероглифы) в самом Access-е не показываются.
Из-за чего моя прога может говорить, что неизвестный формат? Может чего поставить нужно?
Hello, Cover!
You wrote on Tue, 08 Jul 2003 17:10:34 GMT:
C> Вот интересно, у меня прога, которая читает данные из Access-овской C> базы. Я её специально переделывал, чтобы она в win98 работала с C> юникодом, а она мне пишет на файл, созданный в Access2k (который в win98 C> прекрасно работает), что он в неизвестном формате, а если в Access-е C> пересохранить базу в "предыдущую версию", то юникодовские символы C> (иероглифы) в самом Access-е не показываются.
C> Из-за чего моя прога может говорить, что неизвестный формат? Может чего C> поставить нужно?
Я не совсем понял стоит ли на той машине Access2000? Если стоит то хз. Иначе поставь MDAC поновее (я не помню именно в каком появилась эта поддержка то ли 2.5 то ли 2.6)
With best regards, Igor Evgrafov. E-mail: Don't reply use ievgrafo<AT>systems21{DOT}ru
Здравствуйте, GarryIV, Вы писали:
GIV>Hello, Cover! GIV>You wrote on Tue, 08 Jul 2003 17:10:34 GMT:
C>> Вот интересно, у меня прога, которая читает данные из Access-овской C>> базы. Я её специально переделывал, чтобы она в win98 работала с C>> юникодом, а она мне пишет на файл, созданный в Access2k (который в win98 C>> прекрасно работает), что он в неизвестном формате, а если в Access-е C>> пересохранить базу в "предыдущую версию", то юникодовские символы C>> (иероглифы) в самом Access-е не показываются.
C>> Из-за чего моя прога может говорить, что неизвестный формат? Может чего C>> поставить нужно?
GIV>Я не совсем понял стоит ли на той машине Access2000? Если стоит то хз. Иначе поставь MDAC поновее (я не помню именно в каком появилась эта поддержка то ли 2.5 то ли 2.6)
GIV>With best regards, Igor Evgrafov. E-mail: Don't reply use ievgrafo<AT>systems21{DOT}ru
Причину я нашел (совершенно случайно в MSDN):
[msdn]
This error message occurs because the MFC DAO classes that ship with Visual C++ 6.0 load DAO 3.5 (Dao350.dll) by default. DAO 3.5 uses Jet 3.5, which can only open Jet 3.5 format (or earlier) databases. Access 2000 creates Jet 4.0 format database files, which are unrecognizable to Jet 3.5. To successfully open an Access 2000 database using the MFC DAO classes, you need to use DAO 3.6 (Dao360.dll). DAO 3.6 uses Jet 4.0, which can open any available Access database format.
[/msdn]
Теперь у меня новая проблема.
В том же MSDN написано, как это исправить:
[msdn]
Modify the Daocore.cpp file in the MFC SRC directory. You will receive the following comment:
// Determine whether to use DAO 3.6, 3.5, or 3.0
// Use DAO 3.0 if DLL build and not built with MFC 4.21 or later
// Use DAO 3.6 if MFC 6.01 or later
// otherwise, DAO 3.5
Add the following lines:
#undef _MFC_VER
#define _MFC_VER 0x0601
Rebuild the library for the variant you need. For example, to build the static MFC library, debug version, non-Unicode, with no browser files use the following command at the command prompt in the MFC\SRC folder:
nmake DEBUG=1
for release:
nmake DEBUG=0
for unicode builds:
nmake DEBUG=1 UNICODE=1
nmake DEBUG=0 UNICODE=1
NOTE: You need to make certain that the compiler tools are in your path. If not, you may need to run the Vcvars32.bat file located in the Visual C++ \BIN folder. Also note that when you build these new versions of the libraries, they will be copied over the top of the existing ones in the MFC\LIB folder so you may want to save the old ones first.
[/msdn]
(к слову, я испольую MFC статично)
Так вот чего-то у меня не получается перекомпилить библиотеки так, как написано в msdn. Может кто знает, где можно достать уже перекомпиленные библиотеки под JET4? Или напишите по-подробнее, как эти библиотеки перекомпиливаются.
Если подробнее, ошибки возникают после запуска nmake DEBUG=0 UNICODE=1:
cl @C:\DOCUME~1\Admin\LOCALS~1\Temp\nma00244.
NMAKE : fatal error U1077: 'cl' : return code '0x80'
Stop.
Здравствуйте, Cover, Вы писали:
C>Теперь у меня новая проблема. C>В том же MSDN написано, как это исправить: C>[msdn] C>Modify the Daocore.cpp file in the MFC SRC directory. You will receive the following comment:
If you're using the static MFC library, life is a little more difficult. The MSDN™ article mentioned earlier advises that you edit daocore.cpp and rebuild MFC. Yikes! That's a bit drastic for my taste. You should never rebuild MFC if you can avoid it. Better to confine whatever workarounds you need to your own project. Life is safer and more predictable if you make a hard and fast rule that the MFC libraries and code hierarchy are off limits. In fact, you should do what I do as soon as I install any new version of MFC or any SDK—set the read-only attribute on all the files.
But then how can you make MFC use DAO360.DLL in a static MFC build? Easy. Just copy the offending MFC source file (in this case, daocore.cpp) to your code directory, make the changes, and add it to your project. This is always a better way to modify MFC than munging MFC directly. When the linker needs a function or symbol from daocore.obj, it'll find the one in your modified version and, therefore, never need to load daocore.obj from MFC42.LIB. Of course, most MFC modules won't compile outside of their context; there are always some #include files from \mfc\src that you need. The easiest way to find them is just keep compiling and fixing until there are no more errors to fix. For daocore.cpp it turns out you need afximpl.h and daoimpl.h. afximpl.h is the MFC main internal include file, but in fact the only thing daocore.cpp needs from afximpl.h is _countof, so it's easier to copy the definition.
// Add these lines to the top of daocore.cpp#include"daoimpl.h"#define _countof(array) \
(sizeof(array)/sizeof(array[0]))
#undef _MFC_VER
#define _MFC_VER 0x0601
Once you add these lines to daocore.cpp and copy daoimpl.h to your project, daocore.cpp will compile with only a single warning, which you can safely ignore. And since you've redefined _MFC_VER to 0x0601, _AfxDetermineDaoVersion will now use DAO 3.6 (DAO360.DLL). Problem solved.
Just don't forget—this is only a stopgap measure! Once the Redmondtonians release the next MFC, you can return to life as usual. But you should remember this general technique: if you're absolutely, positively sure you need to modify MFC, don't modify the source directly. Instead, copy the module you want to change, plus any #include files and #defines it needs, and add it to your project. This method works whether you're linking with MFC as a static or dynamic library.
