I have a database that when opened contains 75 rows in a table. When queried through ucanaccess it returns 74. A count query also returns a count of 74. When saved as an accdb the proper 75 rows are returned, but I can't get the users to continually re-save their fles before submittal. Ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, your db is likely corrupted, so you just have to use the compact and repair access tool (even if access can read all records). See: http://stackoverflow.com/questions/24975014/java-ucanaccess-doesnt-detect-all-items/24983702#24983702
and https://sourceforge.net/p/ucanaccess/discussion/help/thread/defd3993/
But please, before doing that, try to execute:
package trying.damage;
import java.io.File;
import java.io.IOException;
import com.healthmarketscience.jackcess.Database;
import com.healthmarketscience.jackcess.DatabaseBuilder;
public class Damage {
public static void main(String[] s) throws IOException{
File file=new File("<file>");
DatabaseBuilder dbu=new DatabaseBuilder();
dbu.setReadOnly(true);
dbu.setFile(file);
Database db= dbu.open();
System.out.println("format: "+db.getFileFormat());
System.out.println("rows nr:"+db.getTable("<table75r>").getRowCount());
}
}
</table75r></file>
If it prints "rows nr: 74", please open a ticket to the jackcess team posting your database still corrupted (obviously if there aren't private data).
That would be great because this seems to be a common problem.
And please, let me know your findings.
Last edit: Marco Amadei 2014-09-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
run:
log4j:WARN No appenders could be found for logger (com.healthmarketscience.jackcess.impl.DatabaseImpl).
log4j:WARN Please initialize the log4j system properly.
format: V2000 [VERSION_4]
rows nr:74
BUILD SUCCESSFUL (total time: 0 seconds)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This issue, which is due to a misalignment between table metadata and data in damaged mdb/accdb, has been solved in the 2.0.9.
Thank you for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a database that when opened contains 75 rows in a table. When queried through ucanaccess it returns 74. A count query also returns a count of 74. When saved as an accdb the proper 75 rows are returned, but I can't get the users to continually re-save their fles before submittal. Ideas?
Yes, your db is likely corrupted, so you just have to use the compact and repair access tool (even if access can read all records). See:
http://stackoverflow.com/questions/24975014/java-ucanaccess-doesnt-detect-all-items/24983702#24983702
and
https://sourceforge.net/p/ucanaccess/discussion/help/thread/defd3993/
But please, before doing that, try to execute:
package trying.damage;
import java.io.File;
import java.io.IOException;
import com.healthmarketscience.jackcess.Database;
import com.healthmarketscience.jackcess.DatabaseBuilder;
public class Damage {
public static void main(String[] s) throws IOException{
File file=new File("<file>");
DatabaseBuilder dbu=new DatabaseBuilder();
dbu.setReadOnly(true);
dbu.setFile(file);
Database db= dbu.open();
System.out.println("format: "+db.getFileFormat());
System.out.println("rows nr:"+db.getTable("<table75r>").getRowCount());
}
}
</table75r></file>
If it prints "rows nr: 74", please open a ticket to the jackcess team posting your database still corrupted (obviously if there aren't private data).
That would be great because this seems to be a common problem.
And please, let me know your findings.
Last edit: Marco Amadei 2014-09-09
Thanks Marco - i'll raise a ticket:
run:
log4j:WARN No appenders could be found for logger (com.healthmarketscience.jackcess.impl.DatabaseImpl).
log4j:WARN Please initialize the log4j system properly.
format: V2000 [VERSION_4]
rows nr:74
BUILD SUCCESSFUL (total time: 0 seconds)
This issue, which is due to a misalignment between table metadata and data in damaged mdb/accdb, has been solved in the 2.0.9.
Thank you for your help.