ZapTools Update

[ubu]

Did you follow this instruction? It is important....

Update: Added functionality in a new config file for zapimport that allows the tool to reuse the XML that GBPVR downloads to populate its EPG rather than redownloading the entire XML from Zap2it Labs. This is a feture that can save Zap2it Labs bandwidth. To use this functionality you must set the <SaveZap2itXML> tag in the config.xml file of GBPVR to true and set the UseGBPVR_XML value in the new zapimport config file to true.

As I said in my earlier post, I have <UseGBPVR_XML> set to true. As I'm already using the zapdata.xml reuse feature, the <Save_Zap2itXML> was already set to true. The 5.1 version of zapimport.exe (which I notice is no longer available on the wiki) is still working fine - GBPVR produces the zapdata.xml file and zapimport creates an excellent zapdb.mdb. The 5.5 version, on the other hand, produces the error we all seem to be experiencing.

I'm trying to get a .Net 2.0/SQLite version of the EPGMovieDate utility up on the wiki. It relies on reading the zapdb database so I have a vested interest in zaptools working with SQLite too.

[Excelsior]

I got it to work after some doing some googling. Add this to the top under the "<configuration>" tag of the Zapimport.exe.config. I attached the working config file


<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SQLite"/>
<add name="SQLite Data Provider" invariant="System.Data.SQLite"
description=".Net Framework Data Provider for SQLite" type="System.Data.SQLite.SQLiteFactory, System.Data.SQLite" />
</DbProviderFactories>
</system.data>

[ubu]

I got it to work after some doing some googling. Add this to the top under the "<configuration>" tag of the Zapimport.exe.config. I attached the working config file

<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SQLite"/>
<add name="SQLite Data Provider" invariant="System.Data.SQLite"
description=".Net Framework Data Provider for SQLite" type="System.Data.SQLite.SQLiteFactory, System.Data.SQLite" />
</DbProviderFactories>
</system.data>

You're right. The new version of zapimport does work with SQLite. But I'm trying to use it with the MS Access mdb files. The error message I'm getting (and I assume the other folks too) is moaning on about the OleDbConnection (as used by the MS Jet engine) and not the SQLite DbConnection.

[ydekmekji]

nope doesn't work for me

[Anthony]

Excelsior,

Nope, your config file didn't work for me either. I get the same Windows crash box (send info to Microsoft...).

The only difference I could see was an additional line in the log file:

Using Path C:\Program Files\devnz\gbpvr\
Begining zapdb.mdb update process...
Removing GBPVR Recording Entries...
Loading GBPVR Recording Entries...

Compared to the original log file:

Using Path C:\Program Files\devnz\gbpvr\
Begining zapdb.mdb update process...
Removing GBPVR Recording Entries...

UncleJohnsBand,

Yes, I have set both options to true. I also tried them set to false, and it performed the same?

I don't know if this is normal or not, but I did notice a Zap2it.xml file is created in the ROOT directory of my C: drive (about 1.4 Meg).

Anthony

[UncleJohnsBand]

Ok...it appears that I did not test the OLE connection for Access as well as I should have. :o

The current release should work fine for a SQLite version of Zapdb and either the Access or SQLite version of GBPVR.

The problem stems from how Acess and SQLite differ in caching transactions and handling transactions......

Just to confirm....the only probelms people are seeing is if they are still using an Access based Zapdb.mdb file.

Plesae let me know if you are using the SQLite version of Zapdb.db3 and are having issues with zapimport.

I will work on the access issue....it may end up having to be an Access only release do to the differences in how they handle transaction and caching.

[ubu]

The current release should work fine for a SQLite version of Zapdb and either the Access or SQLite version of GBPVR.

Thanks. I'll try the zapdb.db3/Access gbpvr.mdb combo and let you know if I hit any problems.

The problem stems from how Acess and SQLite differ in caching transactions and handling transactions......
.........
I will work on the access issue....it may end up having to be an Access only release do to the differences in how they handle transaction and caching.

I should probably ask this question in the Developers forum but, just out of interest, why is zapimport using transactions at all? I notice that the only time a commit of the transaction is done is right before the connection is closed in DatabaseHelper.cs. Is the idea that you may want to put in additional commits in the future to enable smaller logical units of work? I'm finding, in my own code, that mass updates of the gbpvr SQLite db are taking forever compared with Access and I was wondering if doing a commit every few hundred updates would help. Perhaps only use a transaction when the DbProviderFactory is SQLite and not use one when it's Access? (Paradoxically, SQLite selects from zapdb seem to be way faster than Access.)

[UncleJohnsBand]

Thanks. I'll try the zapdb.db3/Access gbpvr.mdb combo and let you know if I hit any problems.

Let me know how it goes.....

I should probably ask this question in the Developers forum but, just out of interest, why is zapimport using transactions at all? I notice that the only time a commit of the transaction is done is right before the connection is closed in DatabaseHelper.cs. Is the idea that you may want to put in additional commits in the future to enable smaller logical units of work? I'm finding, in my own code, that mass updates of the gbpvr SQLite db are taking forever compared with Access and I was wondering if doing a commit every few hundred updates would help. Perhaps only use a transaction when the DbProviderFactory is SQLite and not use one when it's Access? (Paradoxically, SQLite selects from zapdb seem to be way faster than Access.)

SQLite does not automatically hold inserts and deletes unless you explixitly start and comit transactions....wheras the OLEDB interface into access does.....

You will notice I call GetOpenZAPDbConnection() which returns to the caller an open connection. This connection has a transaction associated with it. This transaction is started in the method OpenZapDB() which is called by the GetOpenZAPDbConnection() method.

That is why you only see the trans being comitted when the connection is closed....because it has already been open via the first call in the db helper method.

Without the transaction calls the processing time for a single zapimport runs about an hour.....with them in it run in less than a minute.....just a "slight" difference...

[Anthony]

> the only probelms people are seeing is if they are still using
> an Access based Zapdb.mdb file.
> Please let me know if you are using the SQLite version
> of Zapdb.db3 and are having issues with zapimport.

I apologize for being a total newbie, but I have no idea which database I am using, or how to change it?

I am using the newest "97" version of GBPVR, upgraded from 96.12.

How would I determine the database type, and how would I change it if I wanted to?

Anthony

[ubu]

> I am using the newest "97" version of GBPVR, upgraded from 96.12.

How would I determine the database type, and how would I change it if I wanted to?

At the beginning of the Zapimport.exe.config file you will see two database sections, one for Zap and one for GBPVR. They are currently both pointing to Access. Below that, you will see commented out "template" sections for both Access and SQLite. If you replace the 4 lines in the Zap database section with the equivalent 4 lines from the SQLite template section below, you can run zapimport against a SQLite zapdb and an Access gbpvr db.

If, later, you convert GBPVR to use SQLite (and you probably should if you want to take advantage of future releases), using the ChangeDatabase utility, you will need to switch the GBPVR Database section in Zapimport.exe.config to point to SQLite also.