This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
(1) |
Mar
(53) |
Apr
(28) |
May
(5) |
Jun
(7) |
Jul
(16) |
Aug
(15) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(9) |
Feb
(7) |
Mar
(1) |
Apr
(7) |
May
(6) |
Jun
|
Jul
(15) |
Aug
(10) |
Sep
(2) |
Oct
(12) |
Nov
(3) |
Dec
(2) |
2002 |
Jan
(2) |
Feb
(12) |
Mar
(33) |
Apr
(30) |
May
(5) |
Jun
(18) |
Jul
(18) |
Aug
(47) |
Sep
(8) |
Oct
(7) |
Nov
(8) |
Dec
(13) |
2003 |
Jan
(48) |
Feb
(8) |
Mar
(10) |
Apr
(30) |
May
(6) |
Jun
(8) |
Jul
(19) |
Aug
(36) |
Sep
(19) |
Oct
(16) |
Nov
(11) |
Dec
(17) |
2004 |
Jan
(11) |
Feb
(22) |
Mar
(52) |
Apr
(45) |
May
(18) |
Jun
(72) |
Jul
(14) |
Aug
(31) |
Sep
(19) |
Oct
(27) |
Nov
(19) |
Dec
(25) |
2005 |
Jan
(16) |
Feb
(46) |
Mar
(50) |
Apr
(3) |
May
(21) |
Jun
(3) |
Jul
(24) |
Aug
(33) |
Sep
(25) |
Oct
(23) |
Nov
(30) |
Dec
(20) |
2006 |
Jan
(12) |
Feb
(11) |
Mar
(8) |
Apr
(15) |
May
(27) |
Jun
(15) |
Jul
(19) |
Aug
(5) |
Sep
(9) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
2007 |
Jan
|
Feb
(3) |
Mar
(18) |
Apr
(5) |
May
(9) |
Jun
|
Jul
(10) |
Aug
(3) |
Sep
(8) |
Oct
(1) |
Nov
(7) |
Dec
(9) |
2008 |
Jan
(2) |
Feb
|
Mar
(10) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(9) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(8) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(1) |
Dec
(20) |
2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
(7) |
May
|
Jun
(23) |
Jul
(3) |
Aug
(6) |
Sep
(1) |
Oct
(4) |
Nov
(1) |
Dec
|
2011 |
Jan
(1) |
Feb
(26) |
Mar
(25) |
Apr
(11) |
May
(5) |
Jun
(5) |
Jul
(2) |
Aug
(39) |
Sep
(12) |
Oct
(6) |
Nov
|
Dec
|
2012 |
Jan
(19) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(3) |
2013 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
|
May
(7) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2014 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
(5) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Brian B. <ca...@um...> - 2000-04-02 17:31:14
|
Carl, Sorry not to respond sooner, I've taken what you have here but structured it a little bit different. there is a new file backend.c that takes care of setting up the datatypes table and such which can be registered using a GHashTable. That way, an application can register its own backend to export to without it being predefined by us. Now, of course there are some builtin ones. Anyway, to do this, I introduced two new functions mdb_init() and mdb_exit() mdb_init() needs to be called to initialize the library (must be called prior to any other mdb calls). mdb_exit() is the corresponding function for when the program is done with libmdb. Note on threads: mdb_init() and mdb_register_backend() need to be called in a synchronized manner (for instance in the main thread before creating subthreads). I've changed all the files in the util/ directory, but if you have any programs using libmdb, they'll have to have mdb_init() added at the top. Brian On Mon, 27 Mar 2000, Carl Seutter wrote: > I started to look at modifying util/schema.c to provide the ability to > generate different schemas. Here are the recommended changes: > > include/mdbtools.h > > enum { > USE_ACCESS_TYPES = 0, > USE_ORACLE_TYPES = 1, > USE_SYBASE_TYPES = 2, > USE_SQLSERVER_TYPES = 3, > USE_INFORMIX_TYPES = 4 > }; > /* > * column data types > * these must be in the same order as the > * types defined above > * > */ > static char *column_types[5][16] = { > /* Access data types */ > {"Unknown 0x00", > "Boolean", > "Byte", > "Integer", > "Long Integer", > "Currency", > "Single", > "Double", > "DateTime (Short)", > "Unknown 0x09", > "Text", > "OLE", > "Memo/Hyperlink", > "Unknown 0x0d", > "Unknown 0x0e", > "Replication ID"}, > /* Oracle data types */ > {"Oracle_Unknown 0x00", > "CHAR", > "NUMBER", > "NUMBER", > "NUMBER", > "NUMBER", > "NUMBER", > "NUMBER", > "DATE", > "Oracle_Unknown 0x09", > "VARCHAR2", > "BLOB", > "BLOB", > "Oracle_Unknown 0x0d", > "Oracle_Unknown 0x0e", > "NUMBER"}, > /* Sybase data types */ > {"Sybase_Unknown 0x00", > "Sybase_Boolean", > "Sybase_Byte", > "Sybase_Integer", > "Sybase_Long Integer", > "Sybase_Currency", > "Sybase_Single", > "Sybase_Double", > "Sybase_DateTime (Short)", > "Sybase_Unknown 0x09", > "Sybase_Text", > "Sybase_OLE", > "Sybase_Memo/Hyperlink", > "Sybase_Unknown 0x0d", > "Sybase_Unknown 0x0e", > "Sybase_Replication ID"}, > /* SQL Server data types */ > {"SQLserver_Unknown 0x00", > "SQLserver_Boolean", > "SQLserver_Byte", > "SQLserver_Integer", > "SQLserver_Long Integer", > "SQLserver_Currency", > "SQLserver_Single", > "SQLserver_Double", > "SQLserver_DateTime (Short)", > "SQLserver_Unknown 0x09", > "SQLserver_Text", > "SQLserver_OLE", > "SQLserver_Memo/Hyperlink", > "SQLserver_Unknown 0x0d", > "SQLserver_Unknown 0x0e", > "SQLserver_Replication ID"}, > /* Informix data types */ > {"Informix_Unknown 0x00", > "Informix_Boolean", > "Informix_Byte", > "Informix_Integer", > "Informix_Long Integer", > "Informix_Currency", > "Informix_Single", > "Informix_Double", > "Informix_DateTime (Short)", > "Informix_Unknown 0x09", > "Informix_Text", > "Informix_OLE", > "Informix_Memo/Hyperlink", > "Informix_Unknown 0x0d", > "Informix_Unknown 0x0e", > "Informix_Replication ID"} > }; > > By moving these defines to the header file, the array's don't have to be > re-created each time the function mdb_get_coltype_string located in > libmdb/table.c is called. Also for a maintanable environment wouldn't > it be easier if all the column definitions are together along with the > supported databases to generate for? > > > libmdb/table.c: > 1) change char *mdb_get_coltype_string(int col_type) to char > *mdb_get_coltype_string(int col_type, int db_type) > 2) in mdb_get_coltype_string change > return column_types[col_type]; to > return column_types[db_type][col_type]; > 3) in mdb_table_dump change > mdb_get_coltype_string(col->col_type) to > mdb_get_coltype_string(col->col_type,USE_ACCESS_TYPES) > > util/schema.c > 1) change int i, j,k; to > int i, j, k, schema_type; > 2) change if (argc <2) et al to > if (argc < 3) { > fprintf (stderr, "Usage: %s <file> > <schema>\n",argv[0]); > fprintf (stderr, " valid values for schema are: > oracle, sybase, sqlserver, access, informix\n"); > fprintf (stderr, " the default is access\n"); > exit (1); > } > 3) add the following code before the open database > if (strcasecmp(argv[2],"oracle") == 0) > schema_type = USE_ORACLE_TYPES; > else if (strcasecmp(argv[2],"sybase") == 0) > schema_type = USE_SYBASE_TYPES; > else if (strcasecmp(argv[2],"sqlserver") == 0) > schema_type = USE_SQLSERVER_TYPES; > else if (strcasecmp(argv[2],"informix") == 0) > schema_type = USE_INFORMIX_TYPES; > else > schema_type = USE_ACCESS_TYPES; > 4) change the call to mdb_get_coltype_string from > mdb_get_coltype_string (col->col_type) to > mdb_get_coltype_string (col->col_type,schema_type) > 5) added this inside the if (col-> col_size !=0) and before the > fprintf > if (schema_type == USE_ORACLE_TYPES && col->col_type == > MDB_SDATETIME) > schema_type = schema_type; > else > > > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev > |
From: <kn...@gr...> - 2000-03-30 04:34:47
|
These changes make the string values of the empty string more tolerable. I suspect that the condition here is a "null" value in the column entry. I leave it to people more database aware as to whether a "null" value for a string type is equivalent to "". I also changed the mdb-array.c to output default values of "0" when nulls were encountered in the cases of MDB_INT and MDB_LONGINT, matching the value of "" for MDB_TEXT and MDB_MEMO as well as fixing some escape problems for C. diff -r mdbtools/src/libmdb/data.c /tmp/mdbtools/src/libmdb/data.c 261c261 < return "(oops)"; --- > return ""; 268c268 < return "(oops)"; --- > return ""; -- Karl -- begin 644 mdb-array.c M+RH@341"(%1O;VQS("T@02!L:6)R87)Y(&9O<B!R96%D:6YG($U3($%C8V5S M<R!D871A8F%S92!F:6QE"B J($-O<'ER:6=H=" @*$,I(#(P,# @0G)I86X@ M0G)U;G,*("H*("H*("H@5&AI<R!L:6)R87)Y(&ES(&9R964@<V]F='=A<F4[ M('EO=2!C86X@<F5D:7-T<FEB=71E(&ET(&%N9"]O<B *("H@;6]D:69Y(&ET M('5N9&5R('1H92!T97)M<R!O9B!T:&4@1TY5($QI8G)A<GD@1V5N97)A;"!0 M=6)L:6,*("H@3&EC96YS92!A<R!P=6)L:7-H960@8GD@=&AE($9R964@4V]F M='=A<F4@1F]U;F1A=&EO;CL@96ET:&5R"B J('9E<G-I;VX@,B!O9B!T:&4@ M3&EC96YS92P@;W(@("AA="!Y;W5R(&]P=&EO;BD@86YY(&QA=&5R('9E<G-I M;VXN"B J"B J(%1H:7,@;&EB<F%R>2!I<R!D:7-T<FEB=71E9"!I;B!T:&4@ M:&]P92!T:&%T(&ET('=I;&P@8F4@=7-E9G5L+ H@*B!B=70@5TE42$]55"!! M3ED@5T%24D%.5%D[('=I=&AO=70@979E;B!T:&4@:6UP;&EE9"!W87)R86YT M>2!O9@H@*B!-15)#2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!005)4 M24-53$%2(%!54E!/4T4N("!3964@=&AE($=.50H@*B!,:6)R87)Y($=E;F5R M86P@4'5B;&EC($QI8V5N<V4@9F]R(&UO<F4@9&5T86EL<RX*("H*("H@66]U M('-H;W5L9"!H879E(')E8V5I=F5D(&$@8V]P>2!O9B!T:&4@1TY5($QI8G)A M<GD@1V5N97)A;"!0=6)L:6,*("H@3&EC96YS92!A;&]N9R!W:71H('1H:7,@ M;&EB<F%R>3L@:68@;F]T+"!W<FET92!T;R!T:&4*("H@1G)E92!3;V9T=V%R M92!&;W5N9&%T:6]N+"!);F,N+" U.2!496UP;&4@4&QA8V4@+2!3=6ET92 S M,S L"B J($)O<W1O;BP@34$@,#(Q,3$M,3,P-RP@55-!+@H@*B\*"B\J('1H M:7,@:7,@:6YH97)I=&5D(&9R;VT@;61B+65X<&]R="YC+"!M;V1I9FEE9"!T M;R!M86ME(&%R<F%Y<R!S:6UI;&%R('1O"B @('1H;W-E(&=E;F5R871E9"!B M>2!P87)S96-S=BYC("HO"@HC:6YC;'5D92 B;61B=&]O;',N:"(*"FUA:6X@ M*&EN="!A<F=C+"!C:&%R("HJ87)G=BD*>PII;G0@<F]W<SL*:6YT(&DL(&HL M(&L["G5N<VEG;F5D(&-H87(@8G5F(%LR,#0X73L*361B2&%N9&QE("IM9&([ M"DUD8D-A=&%L;V=%;G1R>2!E;G1R>3L*361B5&%B;&5$968@*G1A8FQE.PI- M9&)#;VQU;6X@*F-O;#L*+RH@9&]E<VXG="!H86YD;&4@=&%B;&5S(#X@,C4V M(&-O;'5M;G,N("!#86X@=&AA="!H87!P96X_("HO"F-H87(@*F)O=6YD7W9A M;'5E<R!;,C4V73L@"F-H87(@9&5L:6UI=&5R(%M=(#T@(BP@(CL*8VAA<B!Q M=6]T95]T97AT(#T@,3L*:6YT(&-O=6YT.PII;G0@<W1A<G1E9#L*8VAA<B J M8SL*"B!I9B @*&%R9V,@/" R*2 *(" @>PH@(" @(&9P<FEN=&8@*'-T9&5R M<BP@(E5S86=E.B E<R \9FEL93X@/'1A8FQE/EQN(BP@87)G=B!;,%TI.PH@ M(" @(&5X:70@*#$I.PH@("!]"B *(&UD8B ](&UD8E]O<&5N("AA<F=V(%LQ M72D["B *(&UD8E]R96%D7V-A=&%L;V<@*&UD8BP@341"7U1!0DQ%*3L*( H@ M9F]R(" H:2 ](# [(&D@/"!M9&(M/FYU;5]C871A;&]G.R!I*RLI( H@("(&UD8E]R96%D7V-O;'5M;G,@*'1A M8FQE*3L*"2!M9&)?<F5W:6YD7W1A8FQE("AT86)L92D["@D@"@D@9F]R("AJ M(#T@,#L@:B \('1A8FQE+3YN=6U?8V]L<SL@:BLK*2 *"2 @('L*"2 @(" @ M8F]U;F1?=F%L=65S(%MJ72 ](" H8VAA<B J*2!M86QL;V,@*#(U-BD["@D@ M(" @(&)O=6YD7W9A;'5E<R!;:ET@6S!=(#T@)UPP)SL*"2 @(" @;61B7V)I M;F1?8V]L=6UN("AT86)L92P@:B K(#$L(&)O=6YD7W9A;'5E<R!;:ETI.PH) M(" @?0H*"2!F<')I;G1F("AS=&1O=70L("(O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ+UQN(BD["@D@9G!R:6YT9B H<W1D;W5T+" B+RH@5$A)4R!)4R!!3B!! M551/34%424-!3$Q9($=%3D52051%1"!&24Q%+B @1$\@3D]4($5$250@250A M(2$A(2$@*B]<;B(I.PH)(&9P<FEN=&8@*'-T9&]U="P@(B\J*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHO7&XB*3L*"2!F<')I;G1F("AS=&1O=70L(")<;B(I.PH) M(&9P<FEN=&8@*'-T9&]U="P@(B-I;F-L=61E(#QS=&1I;RYH/EQN(BD["@D@ M9G!R:6YT9B H<W1D;W5T+" B(VEN8VQU9&4@7")T>7!E<RYH7")<;B(I.PH) M(&9P<FEN=&8@*'-T9&]U="P@(B-I;F-L=61E(%PB9'5M<"YH7")<;B(I.PH) M(&9P<FEN=&8@*'-T9&]U="P@(EQN(BD["@D@9G!R:6YT9B H<W1D;W5T+" B M8V]N<W0@)7,@)7-?87)R87D@6UT@/2"2!F<')I;G1F("AS=&1O=70L("(L7&XB*3L* M"2 @(" @("!]"@D@(" @('-T87)T960@/2 Q.PH)(" @("!F<')I;G1F("AS M=&1O=70L(")[7'1<=%QT7'0O*B E-F0@*B]<;EQT(BP@8V]U;G0I.PH)(" @ M("!F;W(@("AJ(#T@,#L@:B \('1A8FQE+3YN=6U?8V]L<SL@:BLK*2 *"2 @ M(" @("!["@D)(&9P<FEN=&8@*'-T9&]U="P@(EQT(BD["@D)(&-O;" ](&=? M<'1R7V%R<F%Y7VEN9&5X("AT86)L92T^8V]L=6UN<RP@:BD["@D)(&EF(" H M<75O=&5?=&5X=" F)B *"0D@(" @(" H8V]L+3YC;VQ?='EP92 ]/2!-1$)? M5$585"!\? H)"2 @(" @("!C;VPM/F-O;%]T>7!E(#T]($U$0E]-14U/*2D@ M"@D)(" @>PH)"2 @(" @9G!R:6YT9B H<W1D;W5T+" B7"(B*3L*"0D@(" @ M(&,@/2!B;W5N9%]V86QU97,@6VI=.PH)"2 @(" @9F]R("AK(#T@,#L@:R \ M('-T<FQE;B H8F]U;F1?=F%L=65S(%MJ72D[(&LK*RD*"0D@(" @(" @>PH) M"0D@:68@*"@J8R ]/2 G7"(G*2!\?" H*F,@/3T@)UQ<)RDI"@D)"2 @('L* M"0D)(" @("!F<')I;G1F("AS=&1O=70L(")<7"(I.PH)"0D@("!]"@D)"2!F M<')I;G1F("AS=&1O=70L("(E8R(L("IC*RLI.PH)"2 @(" @("!]"@D)(" @ M("!F<')I;G1F("AS=&1O=70L(")<(B(I.PH)"2 @('T@"@D)(&5L<V4@:68@ M*"@H8V]L+3YC;VQ?='EP92 ]/2!-1$)?3$].1TE.5"D@?'P@"@D)"2 @("AC M;VPM/F-O;%]T>7!E(#T]($U$0E])3E0I*2 F)@H)"0D@('-T<FQE;B H8F]U M;F1?=F%L=65S(%MJ72D@/3T@,"D*"0D@("!["@D)(" @("!F<')I;G1F("AS M=&1O=70L("(P(BD["@D)(" @?0H)"2!E;'-E"@D)(" @>PH)"2 @(" @9G!R M:6YT9B H<W1D;W5T+" B)7,B+"!B;W5N9%]V86QU97,@6VI=*3L*"0D@("!] M"@D)(&EF("AJ("$]('1A8FQE+3YN=6U?8V]L<R M(#$I"@D)(" @>PH)"2 @ M(" @9G!R:6YT9B H<W1D;W5T+" B)7-<;B(L(&1E;&EM:71E<BD["@D)(" @ M?0H)"2!E;'-E"@D)(" @>PH)"2 @(" @9G!R:6YT9B H<W1D;W5T+" B7&XB M*3L*"0D@("!]"@D@(" @(" @?0H)(" @("!F<')I;G1F("AS=&1O=70L(")] M(BD["@D@(" @(&-O=6YT*RL["@D@("!]"@D@9F]R(" H:B ](# [(&H@/"!T M86)L92T^;G5M7V-O;',[(&HK*RD@"@D@("!["@D@(" @(&9R964@*&)O=6YD M7W9A;'5E<R!;:ETI.PH)(" @?0H@(" @(" @?0H@("!]"B *(&UD8E]F<F5E M7VAA;F1L92 H;61B*3L*"B!F<')I;G1F("AS=&1O=70L(")<;GT[7&XB*3L* M(&9P<FEN=&8@*'-T9&]U="P@(EQN8V]N<W0@:6YT("5S7V%R<F%Y7VQE;F=T I:" ]("5D.UQN(BP@"@D@(&%R9W8@6S)=+ H)("!C;W5N="D["@I]"@IE end |
From: <kn...@gr...> - 2000-03-29 21:35:53
|
Here's a couple files for the util subdirectory. Remember, I'm interested in generating C arrays for the data in the Linux world for further "read-only" code generation based upon this data. This code works for all except a few "(oops)"s that I don't think I need right now. -- Karl -- begin 644 mdb-array.c M+RH@341"(%1O;VQS("T@02!L:6)R87)Y(&9O<B!R96%D:6YG($U3($%C8V5S M<R!D871A8F%S92!F:6QE"B J($-O<'ER:6=H=" @*$,I(#(P,# @0G)I86X@ M0G)U;G,*("H*("H*("H@5&AI<R!L:6)R87)Y(&ES(&9R964@<V]F='=A<F4[ M('EO=2!C86X@<F5D:7-T<FEB=71E(&ET(&%N9"]O<B *("H@;6]D:69Y(&ET M('5N9&5R('1H92!T97)M<R!O9B!T:&4@1TY5($QI8G)A<GD@1V5N97)A;"!0 M=6)L:6,*("H@3&EC96YS92!A<R!P=6)L:7-H960@8GD@=&AE($9R964@4V]F M='=A<F4@1F]U;F1A=&EO;CL@96ET:&5R"B J('9E<G-I;VX@,B!O9B!T:&4@ M3&EC96YS92P@;W(@("AA="!Y;W5R(&]P=&EO;BD@86YY(&QA=&5R('9E<G-I M;VXN"B J"B J(%1H:7,@;&EB<F%R>2!I<R!D:7-T<FEB=71E9"!I;B!T:&4@ M:&]P92!T:&%T(&ET('=I;&P@8F4@=7-E9G5L+ H@*B!B=70@5TE42$]55"!! M3ED@5T%24D%.5%D[('=I=&AO=70@979E;B!T:&4@:6UP;&EE9"!W87)R86YT M>2!O9@H@*B!-15)#2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!005)4 M24-53$%2(%!54E!/4T4N("!3964@=&AE($=.50H@*B!,:6)R87)Y($=E;F5R M86P@4'5B;&EC($QI8V5N<V4@9F]R(&UO<F4@9&5T86EL<RX*("H*("H@66]U M('-H;W5L9"!H879E(')E8V5I=F5D(&$@8V]P>2!O9B!T:&4@1TY5($QI8G)A M<GD@1V5N97)A;"!0=6)L:6,*("H@3&EC96YS92!A;&]N9R!W:71H('1H:7,@ M;&EB<F%R>3L@:68@;F]T+"!W<FET92!T;R!T:&4*("H@1G)E92!3;V9T=V%R M92!&;W5N9&%T:6]N+"!);F,N+" U.2!496UP;&4@4&QA8V4@+2!3=6ET92 S M,S L"B J($)O<W1O;BP@34$@,#(Q,3$M,3,P-RP@55-!+@H@*B\*"B\J('1H M:7,@:7,@:6YH97)I=&5D(&9R;VT@;61B+65X<&]R="YC+"!M;V1I9FEE9"!T M;R!M86ME(&%R<F%Y<R!S:6UI;&%R('1O"B @('1H;W-E(&=E;F5R871E9"!B M>2!P87)S96-S=BYC("HO"@HC:6YC;'5D92 B;61B=&]O;',N:"(*"FUA:6X@ M*&EN="!A<F=C+"!C:&%R("HJ87)G=BD*>PII;G0@<F]W<SL*:6YT(&DL("!J M.PIU;G-I9VYE9"!C:&%R(&)U9B!;,C T.%T["DUD8DAA;F1L92 J;61B.PI- M9&)#871A;&]G16YT<GD@96YT<GD["DUD8E1A8FQE1&5F("IT86)L93L*361B M0V]L=6UN("IC;VP["B\J(&1O97-N)W0@:&%N9&QE('1A8FQE<R ^(#(U-B!C M;VQU;6YS+B @0V%N('1H870@:&%P<&5N/R J+PIC:&%R("IB;W5N9%]V86QU M97,@6S(U-ET[( IC:&%R(&1E;&EM:71E<B!;72 ]("(L("(["F-H87(@<75O M=&5?=&5X=" ](#$["FEN="!C;W5N=#L*:6YT('-T87)T960["@H@:68@("AA M<F=C(#P@,BD@"B @('L*(" @("!F<')I;G1F("AS=&1E<G(L(")5<V%G93H@ M)7,@/&9I;&4^(#QT86)L93Y<;B(L(&%R9W8@6S!=*3L*(" @("!E>&ET("@Q M*3L*(" @?0H@"B!M9&(@/2!M9&)?;W!E;B H87)G=B!;,5TI.PH@"B!M9&)? M<F5A9%]C871A;&]G("AM9&(L($U$0E]404),12D["B *(&9O<B @*&D@/2 P M.R!I(#P@;61B+3YN=6U?8V%T86QO9SL@:2LK*2 *(" @>PH@(" @(&5N=')Y M(#T@9U]A<G)A>5]I;F1E>" H;61B+3YC871A;&]G+"!-9&)#871A;&]G16YT M<GDL(&DI.PH@(" @(&EF(" H(7-T<F-M<" H96YT<GDN;V)J96-T7VYA;64L M(&%R9W8@6S)=*2D@"B @(" @("!["@D@=&%B;&4@/2!M9&)?<F5A9%]T86)L M92 H)F5N=')Y*3L*"2!M9&)?<F5A9%]C;VQU;6YS("AT86)L92D["@D@;61B M7W)E=VEN9%]T86)L92 H=&%B;&4I.PH)( H)(&9O<B H:B ](# [(&H@/"!T M86)L92T^;G5M7V-O;',[(&HK*RD@"@D@("!["@D@(" @(&)O=6YD7W9A;'5E M<R!;:ET@/2 @*&-H87(@*BD@;6%L;&]C("@R-38I.PH)(" @("!B;W5N9%]V M86QU97,@6VI=(%LP72 ]("=<,"<["@D@(" @(&UD8E]B:6YD7V-O;'5M;B H M=&%B;&4L(&H@*R Q+"!B;W5N9%]V86QU97,@6VI=*3L*"2 @('T*"@D@9G!R M:6YT9B H<W1D;W5T+" B+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B]<;B(I.PH) M(&9P<FEN=&8@*'-T9&]U="P@(B\J(%1(25,@25,@04X@05543TU!5$E#04Q, M62!'14Y%4D%4140@1DE,12X@($1/($Y/5"!%1$E4($E4(2$A(2$A("HO7&XB M*3L*"2!F<')I;G1F("AS=&1O=70L("(O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M+UQN(BD["@D@9G!R:6YT9B H<W1D;W5T+" B7&XB*3L*"2!F<')I;G1F("AS M=&1O=70L("(C:6YC;'5D92 \<W1D:6\N:#Y<;B(I.PH)(&9P<FEN=&8@*'-T M9&]U="P@(B-I;F-L=61E(%PB='EP97,N:%PB7&XB*3L*"2!F<')I;G1F("AS M=&1O=70L("(C:6YC;'5D92!<(F1U;7 N:%PB7&XB*3L*"2!F<')I;G1F("AS M=&1O=70L(")<;B(I.PH)(&9P<FEN=&8@*'-T9&]U="P@(F-O;G-T("5S("5S M7V%R<F%Y(%M=(#T@>UQN(BP@87)G=B!;,ETL(&%R9W8@6S)=*3L*"@D@8V]U M;G0@/2 P.PH)('-T87)T960@/2 P.PH)('=H:6QE("AM9&)?9F5T8VA?<F]W M("AT86)L92DI( H)(" @>PH)(" @("!I9B H<W1A<G1E9" A/2 P*0H)(" @ M(" @('L*"0D@9G!R:6YT9B H<W1D;W5T+" B+%QN(BD["@D@(" @(" @?0H) M(" @("!S=&%R=&5D(#T@,3L*"2 @(" @9G!R:6YT9B H<W1D;W5T+" B>UQT M7'1<=%QT+RH@)39D("HO7&Y<="(L(&-O=6YT*3L*"2 @(" @9F]R(" H:B ] M(# [(&H@/"!T86)L92T^;G5M7V-O;',[(&HK*RD@"@D@(" @(" @>PH)"2!F M<')I;G1F("AS=&1O=70L(")<="(I.PH)"2!C;VP@/2!G7W!T<E]A<G)A>5]I M;F1E>" H=&%B;&4M/F-O;'5M;G,L(&HI.PH)"2!I9B @*'%U;W1E7W1E>'0@ M)B8@"@D)(" @(" @*&-O;"T^8V]L7W1Y<&4@/3T@341"7U1%6%0@?'P*"0D@ M(" @(" @8V]L+3YC;VQ?='EP92 ]/2!-1$)?345-3RDI( H)"2 @('L*"0D@ M(" @(&9P<FEN=&8@*'-T9&]U="P@(EPB)7-<(B(L(&)O=6YD7W9A;'5E<R!; M:ETI.PH)"2 @('T@"@D)(&5L<V4@"@D)(" @>PH)"2 @(" @9G!R:6YT9B H M<W1D;W5T+" B)7,B+"!B;W5N9%]V86QU97,@6VI=*3L*"0D@("!]"@D)(&EF M("AJ("$]('1A8FQE+3YN=6U?8V]L<R M(#$I"@D)(" @>PH)"2 @(" @9G!R M:6YT9B H<W1D;W5T+" B)7-<;B(L(&1E;&EM:71E<BD["@D)(" @?0H)"2!E M;'-E"@D)(" @>PH)"2 @(" @9G!R:6YT9B H<W1D;W5T+" B7&XB*3L*"0D@ M("!]"@D@(" @(" @?0H)(" @("!F<')I;G1F("AS=&1O=70L(")](BD["@D@ M(" @(&-O=6YT*RL["@D@("!]"@D@9F]R(" H:B ](# [(&H@/"!T86)L92T^ M;G5M7V-O;',[(&HK*RD@"@D@("!["@D@(" @(&9R964@*&)O=6YD7W9A;'5E M<R!;:ETI.PH)(" @?0H@(" @(" @?0H@("!]"B *(&UD8E]F<F5E7VAA;F1L M92 H;61B*3L*"B!F<')I;G1F("AS=&1O=70L(")<;GT[7&XB*3L*(&9P<FEN M=&8@*'-T9&]U="P@(EQN8V]N<W0@:6YT("5S7V%R<F%Y7VQE;F=T:" ]("5D C.UQN(BP@"@D@(&%R9W8@6S)=+ H)("!C;W5N="D["@I]"@IE end begin 644 Makefile.in M"@I32$5,3" ]("]B:6XO<V@*5E!!5$@@/2! <W)C9&ER0 H*=&]P7W-R8V1I M<B ]($!T;W!?<W)C9&ER0 IS<F-D:7(@/2! <W)C9&ER0 IP<F5F:7@@/2! M<')E9FEX0 IE>&5C7W!R969I>" ]($!E>&5C7W!R969I>$ *8FEN9&ER(#T@ M)"AE>&5C7W!R969I>"DO8FEN"FEN9F]D:7(@/2 D*&5X96-?<')E9FEX*2]I M;F9O"FQI8F1I<B ]("0H97AE8U]P<F5F:7@I+VQI8@IM86YD:7(@/2 D*&5X M96-?<')E9FEX*2]M86XO;6%N,0H*0T,@/2! 0T- "D-04$9,04=3(#T@0$-0 M4$9,04=30 I#1DQ!1U,@/2 D*$-04$9,04<I($!#1DQ!1U- "DQ$1DQ!1U,@ M/2! 3$1&3$%'4T *3$E"4R ]($!,24)30 I)3E-404Q,/2! 24Y35$%,3$ * M24Y#(#T@+4D@+BXO:6YC;'5D92!@9VQI8BUC;VYF:6<@+2UC9FQA9W-@"DQ) M0E,@/2 M3" N+B]L:6)M9&(@+6QM9&(@8&=L:6(M8V]N9FEG("TM;&EB<V * M4%)/1U,@/2!P<F-A="!P<FMK9"!P<G1A8FQE('!R9&%T82!P<F1U;7 @;61B M+7-C:&5M82!M9&(M97AP;W)T(&UD8BUT86)L97,@;61B+6AE861E<B!M9&(M M<&%R<V5C<W8@;61B+6%R<F%Y"E!20T%43T)*4R ]('!R8V%T+F\*4%)+2T1/ M0DI3(#T@<')K:V0N;PI04E1!0DQ%3T)*4R ]('!R=&%B;&4N;PI04D1!5$%/ M0DI3(#T@<')D871A+F\*4%)$54U03T)*4R ]('!R9'5M<"YO"E-#2$5-04]" M2E,@/2!S8VAE;6$N;PI%6%!/4E1/0DI3(#T@;61B+65X<&]R="YO"DA%041% M4D]"2E,@/2!H96%D97(N;PI404),14]"2E,@/2!T86)L97,N;PI#4U9/0DI3 M(#T@<&%R<V5C<W8N;PI!4E)!64]"2E,@/2!M9&(M87)R87DN;PH*86QL.B D M*%!23T=3*0H*<')C870Z("0H4%)#051/0DI3*0H))"A#0RD@+6<@+6\@)$ @ M)"A04D-!5$]"2E,I("0H3$E"4RD*"G!R:VMD.B D*%!22TM$3T)*4RD*"20H M0T,I("UG("UO("1 ("0H4%)+2T1/0DI3*2 D*$Q)0E,I"@IP<G1A8FQE.B D M*%!25$%"3$5/0DI3*0H))"A#0RD@+6<@+6\@)$ @)"A04E1!0DQ%3T)*4RD@ M)"A,24)3*0H*<')D871A.B D*%!21$%404]"2E,I"@DD*$-#*2 M9R M;R D M0" D*%!21$%404]"2E,I("0H3$E"4RD*"G!R9'5M<#H@)"A04D1535!/0DI3 M*0H))"A#0RD@+6<@+6\@)$ @)"A04D1535!/0DI3*2 D*$Q)0E,I"@IM9&(M M87)R87DZ("0H05)205E/0DI3*0H))"A#0RD@+6<@+6\@)$ @)"A!4E)!64]" M2E,I("0H3$E"4RD*"FUD8BUS8VAE;6$Z("0H4T-(14U!3T)*4RD*"20H0T,I M("UG("UO("1 ("0H4T-(14U!3T)*4RD@)"A,24)3*0H*;61B+65X<&]R=#H@ M)"A%6%!/4E1/0DI3*0H))"A#0RD@+6<@+6\@)$ @)"A%6%!/4E1/0DI3*2 D M*$Q)0E,I"@IM9&(M=&%B;&5S.B D*%1!0DQ%3T)*4RD*"20H0T,I("UG("UO M("1 ("0H5$%"3$5/0DI3*2 D*$Q)0E,I"@IM9&(M:&5A9&5R.B D*$A%041% M4D]"2E,I"@DD*$-#*2 M9R M;R D0" D*$A%041%4D]"2E,I("0H3$E"4RD* M"FUD8BUP87)S96-S=CH@)"A#4U9/0DI3*0H))"A#0RD@+6<@+6\@)$ @)"A# M4U9/0DI3*2 D*$Q)0E,I"@IC;&5A;CH@"@ER;2 M9B!C;W)E("HN;R D*%!2 M3T=3*0H*+F,N;SH*"20H0T,I("UG("UC("0\("0H24Y#*0H*:6YS=&%L;#H@ M"@E 9F]R('!R;V<@:6X@)"A04D]'4RD[(&1O(%P*"2!E8VAO("(@(" @(" @ M(" @(" @("!C;W!Y:6YG("0D<')O9R!T;R D*&)I;F1I<BDB.R!<"@D@8W @ M)"1P<F]G("0H8FEN9&ER*3L@7 H@(" @(" @(&1O;F4*"G5N:6YS=&%L;#H@ M"@E 9F]R('!R;V<@:6X@)"A04D]'4RD[(&1O(%P*"2!E8VAO("(@(" @(" @ M(" @(" @("!R96UO=FEN9R D)'!R;V<@9G)O;2 D*&)I;F1I<BDB.R!<"@D@ G<FT@+68@)"AB:6YD:7(I+R0D<')O9SL@7 H@(" @(" @(&1O;F4* end |
From: Carl S. <cgs...@wo...> - 2000-03-28 23:35:22
|
forgot to say in function mdb_open Carl Seutter wrote: > All, > > The question was raised about the database password. While the password is > not needed to access the content of the file, for completeness it would be > nice. Therefore, if the following code was added to libmdb/file.c the > database password would then be a part of the mdb structure: > > int key[] = {0x86, 0xfb, 0xec, 0x37, 0x5d, 0x44, 0x9c, 0xfa, 0xc6, > 0x5e, 0x28, 0xe6, 0x13, 0xb6}; > int j,pos; > > /* get the db password located at 0x42 bytes into the file */ > for (pos=0;pos<14;pos++) { > j = mdb_get_int32(mdb,0x42+pos); > j ^= key[pos]; > if ( j != 0) > mdb->db_passwrd[pos] = j; > else > mdb->db_passwrd[pos] = '\0'; > } > > Also, the following line would need to be added to the MdbHandle structure: > char db_passwrd[14]; > > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev |
From: Carl S. <cgs...@wo...> - 2000-03-28 23:24:23
|
All, The question was raised about the database password. While the password is not needed to access the content of the file, for completeness it would be nice. Therefore, if the following code was added to libmdb/file.c the database password would then be a part of the mdb structure: int key[] = {0x86, 0xfb, 0xec, 0x37, 0x5d, 0x44, 0x9c, 0xfa, 0xc6, 0x5e, 0x28, 0xe6, 0x13, 0xb6}; int j,pos; /* get the db password located at 0x42 bytes into the file */ for (pos=0;pos<14;pos++) { j = mdb_get_int32(mdb,0x42+pos); j ^= key[pos]; if ( j != 0) mdb->db_passwrd[pos] = j; else mdb->db_passwrd[pos] = '\0'; } Also, the following line would need to be added to the MdbHandle structure: char db_passwrd[14]; |
From: Carl S. <cgs...@wo...> - 2000-03-27 23:46:09
|
I started to look at modifying util/schema.c to provide the ability to generate different schemas. Here are the recommended changes: include/mdbtools.h enum { USE_ACCESS_TYPES = 0, USE_ORACLE_TYPES = 1, USE_SYBASE_TYPES = 2, USE_SQLSERVER_TYPES = 3, USE_INFORMIX_TYPES = 4 }; /* * column data types * these must be in the same order as the * types defined above * */ static char *column_types[5][16] = { /* Access data types */ {"Unknown 0x00", "Boolean", "Byte", "Integer", "Long Integer", "Currency", "Single", "Double", "DateTime (Short)", "Unknown 0x09", "Text", "OLE", "Memo/Hyperlink", "Unknown 0x0d", "Unknown 0x0e", "Replication ID"}, /* Oracle data types */ {"Oracle_Unknown 0x00", "CHAR", "NUMBER", "NUMBER", "NUMBER", "NUMBER", "NUMBER", "NUMBER", "DATE", "Oracle_Unknown 0x09", "VARCHAR2", "BLOB", "BLOB", "Oracle_Unknown 0x0d", "Oracle_Unknown 0x0e", "NUMBER"}, /* Sybase data types */ {"Sybase_Unknown 0x00", "Sybase_Boolean", "Sybase_Byte", "Sybase_Integer", "Sybase_Long Integer", "Sybase_Currency", "Sybase_Single", "Sybase_Double", "Sybase_DateTime (Short)", "Sybase_Unknown 0x09", "Sybase_Text", "Sybase_OLE", "Sybase_Memo/Hyperlink", "Sybase_Unknown 0x0d", "Sybase_Unknown 0x0e", "Sybase_Replication ID"}, /* SQL Server data types */ {"SQLserver_Unknown 0x00", "SQLserver_Boolean", "SQLserver_Byte", "SQLserver_Integer", "SQLserver_Long Integer", "SQLserver_Currency", "SQLserver_Single", "SQLserver_Double", "SQLserver_DateTime (Short)", "SQLserver_Unknown 0x09", "SQLserver_Text", "SQLserver_OLE", "SQLserver_Memo/Hyperlink", "SQLserver_Unknown 0x0d", "SQLserver_Unknown 0x0e", "SQLserver_Replication ID"}, /* Informix data types */ {"Informix_Unknown 0x00", "Informix_Boolean", "Informix_Byte", "Informix_Integer", "Informix_Long Integer", "Informix_Currency", "Informix_Single", "Informix_Double", "Informix_DateTime (Short)", "Informix_Unknown 0x09", "Informix_Text", "Informix_OLE", "Informix_Memo/Hyperlink", "Informix_Unknown 0x0d", "Informix_Unknown 0x0e", "Informix_Replication ID"} }; By moving these defines to the header file, the array's don't have to be re-created each time the function mdb_get_coltype_string located in libmdb/table.c is called. Also for a maintanable environment wouldn't it be easier if all the column definitions are together along with the supported databases to generate for? libmdb/table.c: 1) change char *mdb_get_coltype_string(int col_type) to char *mdb_get_coltype_string(int col_type, int db_type) 2) in mdb_get_coltype_string change return column_types[col_type]; to return column_types[db_type][col_type]; 3) in mdb_table_dump change mdb_get_coltype_string(col->col_type) to mdb_get_coltype_string(col->col_type,USE_ACCESS_TYPES) util/schema.c 1) change int i, j,k; to int i, j, k, schema_type; 2) change if (argc <2) et al to if (argc < 3) { fprintf (stderr, "Usage: %s <file> <schema>\n",argv[0]); fprintf (stderr, " valid values for schema are: oracle, sybase, sqlserver, access, informix\n"); fprintf (stderr, " the default is access\n"); exit (1); } 3) add the following code before the open database if (strcasecmp(argv[2],"oracle") == 0) schema_type = USE_ORACLE_TYPES; else if (strcasecmp(argv[2],"sybase") == 0) schema_type = USE_SYBASE_TYPES; else if (strcasecmp(argv[2],"sqlserver") == 0) schema_type = USE_SQLSERVER_TYPES; else if (strcasecmp(argv[2],"informix") == 0) schema_type = USE_INFORMIX_TYPES; else schema_type = USE_ACCESS_TYPES; 4) change the call to mdb_get_coltype_string from mdb_get_coltype_string (col->col_type) to mdb_get_coltype_string (col->col_type,schema_type) 5) added this inside the if (col-> col_size !=0) and before the fprintf if (schema_type == USE_ORACLE_TYPES && col->col_type == MDB_SDATETIME) schema_type = schema_type; else |
From: leandro <le...@ib...> - 2000-03-27 17:16:55
|
ok.... I'm trying to steal some data out of a dbm file... because MS Access keeps asking me my username and passwd... I don't have it, so I'd like somebody to help accomplish this..... anybody ??? |
From: Brian B. <ca...@um...> - 2000-03-22 02:25:52
|
I've updated the HACKERS file to include some information on indexes. Basically, it goes something like this: The fields in the table definition page that I had thought was a counter of the number of datapages is actually a count of the number of indexes. It just so happens that the files I was looking at had identical numbers for both! The area that iterates for that number of times shows the number of rows (bytes 0-3) and then (for duplicate indexes) the number of distinct values for that indexed column (bytes 4-7) 58 bytes (possibly a variable number) after the column names, the index names are listed in similar fashion (a 1 byte length followed by the name). It is unclear to me presently (though to be honest I haven't spent much time on it yet) how the indexes map to columns or how this index definition points at a index page, but its a start. Brian |
From: Brian B. <ca...@um...> - 2000-03-19 14:56:21
|
The new version is at http://download.sourceforge.net/mdbtools/mdbtools-0.1.tgz |
From: Brian B. <ca...@um...> - 2000-03-19 03:51:58
|
This fix is in CVS...I screwed something up when changing the way we go after data rows. Brian > After making sure mdb-export is returning the proper number of rows, |
From: Brian B. <ca...@um...> - 2000-03-19 03:30:19
|
Hi all, I've added support for null columns to data.c It's still preliminary and needs a better way to pass the information back up to the utilities (currently it copys a zero length string when binding during the call to mdb_fetch_row()). The way it works is this: At the end of each data row there is a bitmask of 1 byte per 8 columns. Each bit indicates the presence of a data value for that column (1 indicates value present, 0 indicates a NULL). Column 1 is the low order bit in the first byte. So for a 12 column table with nulls in columns 6 and 12 the bitmask would be 0xbf07 (extra bits are 0'd). After making sure mdb-export is returning the proper number of rows, I'd like to make a new release (0.1 I guess), unless there are any objections. Brian |
From: Brian B. <ca...@um...> - 2000-03-17 23:53:17
|
It made it, I had my LUG meeting last night, so I wasn't able to do anything with it 'til tonight. (BTW send me an email addy to use for the AUTHORS file). Anyway, it's in CVS Brian On Fri, 17 Mar 2000, Carl Seutter wrote: > I'm not sure the file last night made it. Anyway, this is my first > attempt at doing an autoconf. If so, then this is an update. There are > rules for compile, install, uninstall, and clean. > |
From: Carl S. <cgs...@wo...> - 2000-03-17 21:24:57
|
I'm not sure the file last night made it. Anyway, this is my first attempt at doing an autoconf. If so, then this is an update. There are rules for compile, install, uninstall, and clean. |
From: Carl S. <cgs...@wo...> - 2000-03-17 01:28:17
|
Here's the start of the autoconf. As this is my first attempt, I'm not sure that everything is here. However, it does compile all the code. I still need to add an install rule but here's what I have. Carl |
From: <kn...@gr...> - 2000-03-16 13:56:10
|
My rule on this is as follows (it's known as Nyberg's law - feel free to reference it!): It's always easier to make a working program fast than it is to make a fast program work. Meaning, of course, take the inefficient, but (not in the formal sense) correct, solution, and let your knowledge and understanding of the problem, your programming skills, and the speed of computer hardware have a chance to catch up. Once you see the whole puzzle, it's often easier to figure out where (and in what order) you should have put the pieces. I have many times coded inefficient (but obvious) solutions to problems and not gotten the elegant solution until much later. Having A solution permits me to move forward with other aspects of a system development without waiting on the perfect solution or being completely blocked. -- Karl -- Date: Thu, 16 Mar 2000 08:34:08 -0500 (EST) From: Brian Bruns <ca...@um...> List-Id: MDB Tools development <mdbtools-dev.lists.sourceforge.net> I just had a revelation about how the datapages work, and thought maybe someone would have a better idea. Table definition pages start out with '02 01' as the first two bytes, while datapages (and this includes catalog pages btw) start out '01 01'. The next two bytes are currently of unknow use, but bytes 4-7 are the parent page of this datapage. So our catalog pages all have '02 00 00 00' for a parent page (page 2...little endian remember). So, page 2 is some sort of definition for the catalog...not all that important to us at the moment. Anyway, one approach to getting the datapages reading correctly would be to do the same thing we do for catalog pages, which is read the entire database for pages with a parent page of the table definition. This is grossly ineffiecient, however it would give the correct results until we can can find someway to get the proper page linkage (if there is a way). What do you think? Brian |
From: Brian B. <ca...@um...> - 2000-03-16 13:40:31
|
I just had a revelation about how the datapages work, and thought maybe someone would have a better idea. Table definition pages start out with '02 01' as the first two bytes, while datapages (and this includes catalog pages btw) start out '01 01'. The next two bytes are currently of unknow use, but bytes 4-7 are the parent page of this datapage. So our catalog pages all have '02 00 00 00' for a parent page (page 2...little endian remember). So, page 2 is some sort of definition for the catalog...not all that important to us at the moment. Anyway, one approach to getting the datapages reading correctly would be to do the same thing we do for catalog pages, which is read the entire database for pages with a parent page of the table definition. This is grossly ineffiecient, however it would give the correct results until we can can find someway to get the proper page linkage (if there is a way). What do you think? Brian |
From: <kn...@gr...> - 2000-03-16 13:05:46
|
I sent in three new programs to be added to the archive (I can't access it right now to confirm that they're there): mdb-tables - trivially lists the non-system tables on a single line I use this in scripts, like: foreach foo (`./tables foo.mdb`) mdb-header - generates C header files from a database mdb-parsecsv - parses a Comma Separated Values file and generates the corresponding C array declarations. Remember, I'm just looking for read access to the data for further data massaging, so this gets all my data into a C program on the UNIX side of the house from a CSV (soon to be mdb-export) file. This level of program meets all the data requirements in my CSV files. -- Karl -- |
From: Brian B. <ca...@um...> - 2000-03-16 11:32:02
|
Karl, easy fix (I just overlooked it), the old code assumes that a fixed length column never varied in size (duh) so a long int is always 4, an int is always 2, etc... so the code passes '0' as the size in the call to mdb_col_to_string() this needs to changes to 'col->col_size' and all will work. I'm sort of stumped on why it reads only 15 items though. Sounds like it reads the first page and stops. The page linkage for data pages is definately something that needs work. BTW, do you mind if we name the utilities 'mdb-'whatever (like changing schema to mdb-schema, tables to mdb-tables)? I'd like them to be unambigious so they can be put in /usr/bin on a distro and not conflict with anything else. Brian On Wed, 15 Mar 2000 kn...@gr... wrote: > That's definitely better. (Sorry I didn't have time to work on it today - > political battles...) The date fields are still missing though. Also, when > I tried this on the full database, it only did the first 15 items and then > quit, although prtable reports (correctly) that there are 475 rows. > > -- Karl -- > > > > 82,99,8,"UPDATE_ID_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None" > > > 82,100,26,"UPDATE_TMSTP_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None" > > > 82,101,40,"DEPT_NM_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None" > > > 82,102,3,"TTL_TP_CL_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None" > > > 82,6291458,4,"SIC_TP_LEN","1998-09-08-17.12.36.000000","1998-09-08-17.12.36.000000",,41,41,1,0, > > > 82,15728641,3,"STD_ENTR_CL_LEN","2000-02-15-11.48.09.000000","2000-02-15-11.48.09.000000",,82,82,0,0, > > 23:03 248 util: ./mdb-export ~/databases/db1.mdb LENGTH > VERSION,ID_VALUE,MAX_LENGTH,IDENTIFIER,CREATE_DATE,LAST_MOD_DATE,EXPIRY_DATE,DEFINED_VERSION,LAST_MOD_VERSION,STATUS,DESCOPED_IND,DESCRIPTION > 82,99,8,"UPDATE_ID_LEN","","","",1,1,1,0,None > 82,100,26,"UPDATE_TMSTP_LEN","","","",1,1,1,0,None > 82,101,40,"DEPT_NM_LEN","","","",1,1,1,0,None > 82,102,3,"TTL_TP_CL_LEN","","","",1,1,1,0,None > 82,6291458,4,"SIC_TP_LEN","","","",41,41,1,0,(oops) > 82,15728641,3,"STD_ENTR_CL_LEN","","","",82,82,0,0,(oops) > > -- prtable output > > number of datarows = 475 > number of columns = 12 > number of datapages = 1 > first data page = 26 > column 0 Name: VERSION Type: Integer(2) > column 1 Name: ID_VALUE Type: Long Integer(4) > column 2 Name: MAX_LENGTH Type: Long Integer(4) > column 3 Name: IDENTIFIER Type: Text(30) > column 4 Name: CREATE_DATE Type: Text(26) > column 5 Name: LAST_MOD_DATE Type: Text(26) > column 6 Name: EXPIRY_DATE Type: Text(26) > column 7 Name: DEFINED_VERSION Type: Integer(2) > column 8 Name: LAST_MOD_VERSION Type: Integer(2) > column 9 Name: STATUS Type: Integer(2) > column 10 Name: DESCOPED_IND Type: Integer(2) > column 11 Name: DESCRIPTION Type: Memo/Hyperlink(0) > > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev > |
From: <kn...@gr...> - 2000-03-16 04:50:07
|
The libmdb/dump.c file needs to have the signature of buffer_dump: void buffer_dump(const char* buf, int start, int end) changed to match the mdbtools.h prototype: void buffer_dump(const unsigned char* buf, int start, int end); -- Karl -- |
From: <kn...@gr...> - 2000-03-16 04:12:53
|
That's definitely better. (Sorry I didn't have time to work on it today - political battles...) The date fields are still missing though. Also, when I tried this on the full database, it only did the first 15 items and then quit, although prtable reports (correctly) that there are 475 rows. -- Karl -- > > 82,99,8,"UPDATE_ID_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None" > > 82,100,26,"UPDATE_TMSTP_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None" > > 82,101,40,"DEPT_NM_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None" > > 82,102,3,"TTL_TP_CL_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None" > > 82,6291458,4,"SIC_TP_LEN","1998-09-08-17.12.36.000000","1998-09-08-17.12.36.000000",,41,41,1,0, > > 82,15728641,3,"STD_ENTR_CL_LEN","2000-02-15-11.48.09.000000","2000-02-15-11.48.09.000000",,82,82,0,0, 23:03 248 util: ./mdb-export ~/databases/db1.mdb LENGTH VERSION,ID_VALUE,MAX_LENGTH,IDENTIFIER,CREATE_DATE,LAST_MOD_DATE,EXPIRY_DATE,DEFINED_VERSION,LAST_MOD_VERSION,STATUS,DESCOPED_IND,DESCRIPTION 82,99,8,"UPDATE_ID_LEN","","","",1,1,1,0,None 82,100,26,"UPDATE_TMSTP_LEN","","","",1,1,1,0,None 82,101,40,"DEPT_NM_LEN","","","",1,1,1,0,None 82,102,3,"TTL_TP_CL_LEN","","","",1,1,1,0,None 82,6291458,4,"SIC_TP_LEN","","","",41,41,1,0,(oops) 82,15728641,3,"STD_ENTR_CL_LEN","","","",82,82,0,0,(oops) -- prtable output number of datarows = 475 number of columns = 12 number of datapages = 1 first data page = 26 column 0 Name: VERSION Type: Integer(2) column 1 Name: ID_VALUE Type: Long Integer(4) column 2 Name: MAX_LENGTH Type: Long Integer(4) column 3 Name: IDENTIFIER Type: Text(30) column 4 Name: CREATE_DATE Type: Text(26) column 5 Name: LAST_MOD_DATE Type: Text(26) column 6 Name: EXPIRY_DATE Type: Text(26) column 7 Name: DEFINED_VERSION Type: Integer(2) column 8 Name: LAST_MOD_VERSION Type: Integer(2) column 9 Name: STATUS Type: Integer(2) column 10 Name: DESCOPED_IND Type: Integer(2) column 11 Name: DESCRIPTION Type: Memo/Hyperlink(0) |
From: Brian B. <ca...@um...> - 2000-03-16 02:31:57
|
Karl, All three of these fixes are in CVS and I can do a mdb-export on the sample database you sent. There seems to be one lingering problem (null memo fields come up "oops", but since we have no explicit support for NULLs, I think that's not too bad). The only big mystery left is why upgraded databases don't seem to start data on the correct page...if we can fix that one, I'd say we have something usable. Brian On Tue, 14 Mar 2000, Brian Bruns wrote: > > On Tue, 14 Mar 2000 kn...@gr... wrote: > > > I've encountered a problem I haven't been able to solve yet. Here's a > > relatively small instance. > > > > A couple things - the variable string data doesn't seem to quite be > > laid out in the same manner as other data. Some of the variable > > length data in the middle exists, while other data exists via some (as > > yet unclear to me) pointer mechanism. Also, the current code > > calculates the number of variable columns all wrong in this instance. > > > > I have hard-coded a 5 in (4 varchar fields and one "memo" field, which > > appears to be somewhat equivalent to a varchar (64K)) - this could be > > wrong, but is closer than the value that comes from the code or the > > HACKERS file description. I was wondering whether it might not be > > more beneficial to parse the data by column (0 .. 11) and select a > > data parse based upon column type, rather than parse by column type > > (fixed columns first, then variable columns), but I haven't been able > > to get past that pointer to the varchar data (in ?? below). The > > actual data does start 31 (decimal) bytes from the end of the data, > > but I can't map a length, unless it's that <0c> sitting at the > > beginning of the data. > > > > The access data: > > > > 82,99,8,"UPDATE_ID_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None" > > 82,100,26,"UPDATE_TMSTP_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None" > > 82,101,40,"DEPT_NM_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None" > > 82,102,3,"TTL_TP_CL_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None" > > 82,6291458,4,"SIC_TP_LEN","1998-09-08-17.12.36.000000","1998-09-08-17.12.36.000000",,41,41,1,0, > > 82,15728641,3,"STD_ENTR_CL_LEN","2000-02-15-11.48.09.000000","2000-02-15-11.48.09.000000",,82,82,0,0, > > > > prtable reports (correctly): > > > > number of datarows = 6 > > number of columns = 12 > > number of datapages = 1 > > first data page = 30 > > column 0 Name: VERSION Type: Integer(2) > > column 1 Name: ID_VALUE Type: Long Integer(4) > > column 2 Name: MAX_LENGTH Type: Long Integer(4) > > column 3 Name: IDENTIFIER Type: Varchar(30) > > column 4 Name: CREATE_DATE Type: Varchar(26) > > column 5 Name: LAST_MOD_DATE Type: Varchar(26) > > column 6 Name: EXPIRY_DATE Type: Varchar(26) > > column 7 Name: DEFINED_VERSION Type: Integer(2) > > column 8 Name: LAST_MOD_VERSION Type: Integer(2) > > column 9 Name: STATUS Type: Integer(2) > > column 10 Name: DESCOPED_IND Type: Integer(2) > > column 11 Name: DESCRIPTION Type: Memo(0) > > > > Ok, three things seem to be happening here. one is that there is an extra pad > character at the end of the row (I wish I could figure out the rules that > this follows...it seems to happen on some tables and not on others...anyway > you'll see it on page 0x001f of the mdb file you sent me, rows end 0xbf 0x0f > instead of the normal 0x0f). So, that's one problem. > > Problem two is that only INDENTIFIER and DESCRIPTION are treated as variable > length (perhaps the required field controls this?)...somthing to look at > anyway, but no answers as of yet. I can't find anything in the column > definition that my be used, but I'll keep looking. > > The third problem is the memo field preprends some info on the front of the > text. 12 bytes it appears... the first 2 seem to indicate length (0x04 for > "None") > > Brian > > > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev > |
From: Brian B. <ca...@um...> - 2000-03-16 02:24:20
|
Ok, I've changed all references to MDB_PGSIZE instead point to mdb->pg_size That way the page size will be initialized with the opening of the mdb file (currently it just sets it to MDB_PGSIZE (2048) but it's easy to change from there). Theoretically this would mean that the same program could open a Jet 4.0 db and a Jet 3.x db at the same time. Brian On Wed, 15 Mar 2000, Carl Seutter wrote: > according to http://msdn.microsoft.com/library/psdk/dasdk/jolt5krp.htm > Jet 4.0 has gone from a 2K to a 4K page. Therefore, the version that > created the file might come into play in determing the page size. > > > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev > |
From: Carl S. <cgs...@wo...> - 2000-03-16 01:05:38
|
according to http://msdn.microsoft.com/library/psdk/dasdk/jolt5krp.htm Jet 4.0 has gone from a 2K to a 4K page. Therefore, the version that created the file might come into play in determing the page size. |
From: Carl S. <cgs...@wo...> - 2000-03-16 00:15:01
|
Data sizes & record overhead information http://msdn.microsoft.com/library/books/dnjet/c6_body_33.htm |
From: Brian B. <ca...@um...> - 2000-03-15 12:40:21
|
Thanks Carl. I've added a resources section to the webpage (mdbtools.sourceforge.net) in which I pretty much plagerize what you just said, hope you don't mind. Brian On Tue, 14 Mar 2000, Carl Seutter wrote: > http://msdn.microsoft.com/library/default.htm > when this page opens, on the left side, click on books, then microsoft > jet database engine programmers guide. There are 13 chapers & 5 > appendices. > > Here's a couple of links that talk about the size of some of the > objects: > > http://msdn.microsoft.com/library/books/dnjet/apa_body.htm > http://msdn.microsoft.com/library/books/dnjet/c1_body_17.htm > http://msdn.microsoft.com/library/books/dnjet/c1_body_18.htm > > > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev > |