Smalltalk › Cincom › VisualWorks

[Bug 7.8] Store-Glorp publishing error with Access

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 5 messages Options
Christian Haider
Reply | Threaded
Open this post in threaded view
♦
♦
|

[Bug 7.8] Store-Glorp publishing error with Access

Christian Haider

While moving to VW 7.8, I publish all Cincom code into a MSAccess Store.

Unfortunately, with the package [Com-Obsolete] Access throws an error (stack trace attached):

'An error occured when writing to the database.

[Microsoft][ODBC-Treiber für Microsoft Access] Syntaxfehler in Abfrageausdruck ''0x''.

No changes to the database have been commited'

(the second line in English would be something like:

                [Microsoft][ODBC driver for Micosoft Access] syntax error in expression “0x”.)

 

The failing SQL expression is:

                'INSERT INTO TW_Blob (primaryKey,blobType,blobData)  VALUES (265857,2,0x)'.

The 3rd parameter “0x” is created by the Glorp.InsertCommand (which is created by GlorpSession>>commandForHomogeneousRows: which is called from GlorpSession>>groupWrite: ) for an empty ByteArray.

 

Here the post error analysis gets a bit harder since all changes to the database are in one Set (UnitOfWork #newObjects) with 2062 elements L. 740 of those are StoreBlobs and one has indeed an empty ByteArray. Unfortunately I have no clue where this comes from…

 

So, I filtered the culprit out by temporarily patching Glorp and published. The result reconciles and compares (tried various Store settings) clean against the database… So, still no idea where the empty ByteArray comes from L

 

I guess there are two questions:

1. where does the empty Blob comes from?

2. should it be legal to insert an empty blob?

 

Cheers,

                Christian


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stackdump.txt (117K) Download Attachment
Alan Knight-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Bug 7.8] Store-Glorp publishing error with Access

Alan Knight-2
It's actually not so difficult to find out where it comes from. If you do an allReferences on the StoreBlob, you'll find it's owned by only on a few things, and one of them is a StorePackage. So this Blob represents the comment for that package, which is an empty string. There are many such blobs in the database, so if Access can't support those, that seems like a significant issue. Or it may be that we're not writing them in a way that Access likes. Also, you don't specify the version of Access, but more recent versions are really just SQL Server, so will behave somewhat differently (and have fewer limitations). It might also just be easier to use something like SQLite rather than access nowadays.


[hidden email]
May 14, 2011 4:53 AM


While moving to VW 7.8, I publish all Cincom code into a MSAccess Store.

Unfortunately, with the package [Com-Obsolete] Access throws an error (stack trace attached):

'An error occured when writing to the database.

[Microsoft][ODBC-Treiber für Microsoft Access] Syntaxfehler in Abfrageausdruck ''0x''.

No changes to the database have been commited'

(the second line in English would be something like:

                [Microsoft][ODBC driver for Micosoft Access] syntax error in expression “0x”.)

 

The failing SQL expression is:

                'INSERT INTO TW_Blob (primaryKey,blobType,blobData)  VALUES (265857,2,0x)'.

The 3rd parameter “0x” is created by the Glorp.InsertCommand (which is created by GlorpSession>>commandForHomogeneousRows: which is called from GlorpSession>>groupWrite: ) for an empty ByteArray.

 

Here the post error analysis gets a bit harder since all changes to the database are in one Set (UnitOfWork #newObjects) with 2062 elements L. 740 of those are StoreBlobs and one has indeed an empty ByteArray. Unfortunately I have no clue where this comes from…

 

So, I filtered the culprit out by temporarily patching Glorp and published. The result reconciles and compares (tried various Store settings) clean against the database… So, still no idea where the empty ByteArray comes from L

 

I guess there are two questions:

1. where does the empty Blob comes from?

2. should it be legal to insert an empty blob?

 

Cheers,

                Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Christian Haider
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Bug 7.8] Store-Glorp publishing error with Access

Christian Haider
In reply to this post by Christian Haider

Thanks for the response and the tip with the references.

 

The empty/missing package comment may be the reason, since [Com-Obsolete] was the only NEW parcel without comment. Other parcels without comment I had in that store already reconciled and published fine.

 

I tested with a brand new package without a comment (not from a parcel) and it gave the same error.

The bug would be then “Error when publishing a new package without comment to MSAccess”.

 

You say “… if Access can't support those [empty blobs], that seems like a significant issue”. Do you mean it is an issue for Access or for Glorp? You didn’t assign an AR, so Cincon will or will not do anything about this?

 

The release notes for vw7.8 says that Store support for MSAccess is in preview (and will be supported, I guess). But in your reply you suggest not using it. What is the story here?

 

The Access driver I use came with Windows 7 64Bit (or Office 64Bit). Version 14.00.4760.1000. I believe this should be the newest, since automatic update is enabled.

 

Cheers,

                Christian

 

 

Von: Alan Knight [mailto:[hidden email]]
Gesendet: Montag, 16. Mai 2011 23:00
An: Christian Haider
Cc: [hidden email]
Betreff: Re: [vwnc] [Bug 7.8] Store-Glorp publishing error with Access

 

It's actually not so difficult to find out where it comes from. If you do an allReferences on the StoreBlob, you'll find it's owned by only on a few things, and one of them is a StorePackage. So this Blob represents the comment for that package, which is an empty string. There are many such blobs in the database, so if Access can't support those, that seems like a significant issue. Or it may be that we're not writing them in a way that Access likes. Also, you don't specify the version of Access, but more recent versions are really just SQL Server, so will behave somewhat differently (and have fewer limitations). It might also just be easier to use something like SQLite rather than access nowadays.


 

[hidden email]
May 14, 2011 4:53 AM

 



While moving to VW 7.8, I publish all Cincom code into a MSAccess Store.

Unfortunately, with the package [Com-Obsolete] Access throws an error (stack trace attached):

'An error occured when writing to the database.

[Microsoft][ODBC-Treiber für Microsoft Access] Syntaxfehler in Abfrageausdruck ''0x''.

No changes to the database have been commited'

(the second line in English would be something like:

                [Microsoft][ODBC driver for Micosoft Access] syntax error in expression “0x”.)

 

The failing SQL expression is:

                'INSERT INTO TW_Blob (primaryKey,blobType,blobData)  VALUES (265857,2,0x)'.

The 3rd parameter “0x” is created by the Glorp.InsertCommand (which is created by GlorpSession>>commandForHomogeneousRows: which is called from GlorpSession>>groupWrite: ) for an empty ByteArray.

 

Here the post error analysis gets a bit harder since all changes to the database are in one Set (UnitOfWork #newObjects) with 2062 elements L. 740 of those are StoreBlobs and one has indeed an empty ByteArray. Unfortunately I have no clue where this comes from…

 

So, I filtered the culprit out by temporarily patching Glorp and published. The result reconciles and compares (tried various Store settings) clean against the database… So, still no idea where the empty ByteArray comes from L

 

I guess there are two questions:

1. where does the empty Blob comes from?

2. should it be legal to insert an empty blob?

 

Cheers,

                Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Christian Haider
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Bug 7.8] Store-Glorp publishing error with Access

Christian Haider
In reply to this post by Christian Haider

Oops…

 

Just found an old „fix“ of mine where I added #useBinding to AccessPlatform which answers false.

Without this, a package without comment publishes just fine J

 

I hope that the original problem that was fixed by that patch is solved… I will watch closely.

 

Sorry for the false alarm.

 

I would still like to know if using Access is advisable (I do like it because it is very light weight and fast).

 

Cheers,

                Christian

 

Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Christian Haider
Gesendet: Dienstag, 17. Mai 2011 10:31
An: [hidden email]
Cc: [hidden email]
Betreff: Re: [vwnc] [Bug 7.8] Store-Glorp publishing error with Access

 

Thanks for the response and the tip with the references.

 

The empty/missing package comment may be the reason, since [Com-Obsolete] was the only NEW parcel without comment. Other parcels without comment I had in that store already reconciled and published fine.

 

I tested with a brand new package without a comment (not from a parcel) and it gave the same error.

The bug would be then “Error when publishing a new package without comment to MSAccess”.

 

You say “… if Access can't support those [empty blobs], that seems like a significant issue”. Do you mean it is an issue for Access or for Glorp? You didn’t assign an AR, so Cincon will or will not do anything about this?

 

The release notes for vw7.8 says that Store support for MSAccess is in preview (and will be supported, I guess). But in your reply you suggest not using it. What is the story here?

 

The Access driver I use came with Windows 7 64Bit (or Office 64Bit). Version 14.00.4760.1000. I believe this should be the newest, since automatic update is enabled.

 

Cheers,

                Christian

 

 

Von: Alan Knight [mailto:[hidden email]]
Gesendet: Montag, 16. Mai 2011 23:00
An: Christian Haider
Cc: [hidden email]
Betreff: Re: [vwnc] [Bug 7.8] Store-Glorp publishing error with Access

 

It's actually not so difficult to find out where it comes from. If you do an allReferences on the StoreBlob, you'll find it's owned by only on a few things, and one of them is a StorePackage. So this Blob represents the comment for that package, which is an empty string. There are many such blobs in the database, so if Access can't support those, that seems like a significant issue. Or it may be that we're not writing them in a way that Access likes. Also, you don't specify the version of Access, but more recent versions are really just SQL Server, so will behave somewhat differently (and have fewer limitations). It might also just be easier to use something like SQLite rather than access nowadays.

 

[hidden email]
May 14, 2011 4:53 AM

 

 

While moving to VW 7.8, I publish all Cincom code into a MSAccess Store.

Unfortunately, with the package [Com-Obsolete] Access throws an error (stack trace attached):

'An error occured when writing to the database.

[Microsoft][ODBC-Treiber für Microsoft Access] Syntaxfehler in Abfrageausdruck ''0x''.

No changes to the database have been commited'

(the second line in English would be something like:

                [Microsoft][ODBC driver for Micosoft Access] syntax error in expression “0x”.)

 

The failing SQL expression is:

                'INSERT INTO TW_Blob (primaryKey,blobType,blobData)  VALUES (265857,2,0x)'.

The 3rd parameter “0x” is created by the Glorp.InsertCommand (which is created by GlorpSession>>commandForHomogeneousRows: which is called from GlorpSession>>groupWrite: ) for an empty ByteArray.

 

Here the post error analysis gets a bit harder since all changes to the database are in one Set (UnitOfWork #newObjects) with 2062 elements L. 740 of those are StoreBlobs and one has indeed an empty ByteArray. Unfortunately I have no clue where this comes from…

 

So, I filtered the culprit out by temporarily patching Glorp and published. The result reconciles and compares (tried various Store settings) clean against the database… So, still no idea where the empty ByteArray comes from L

 

I guess there are two questions:

1. where does the empty Blob comes from?

2. should it be legal to insert an empty blob?

 

Cheers,

                Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Alan Knight-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Bug 7.8] Store-Glorp publishing error with Access

Alan Knight-2
Yes, I was thinking afterwards that you should check if binding is being used.

As far as Access, our current thinking is that this will not become supported, as it is thoroughly deprecated now by Microsoft, and in looking at supporting it we discovered a number of limitations in its support given the more complex SQL that the new Store back-end uses. From Microsoft's Web Site

http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_ObsoleteDataAccessTech

The Microsoft Jet Database Engine 4.0 components entered a state of functional deprecation and sustained engineering, and have not received feature level enhancements since becoming a part of Microsoft Windows in Windows 2000.

and
Instead of Microsoft Jet, Microsoft recommends using Microsoft SQL Server Express Edition or Microsoft SQL Server Compact Edition when developing new, non-Microsoft Access applications requiring a relational data store. These new or converted Jet applications can continue to use Jet with the intention of using Microsoft Office 2003 and earlier files (.mdb and .xls) for non-primary data storage. However, for these applications, you should plan to migrate from Jet to the 2007 Office System Driver. You can download the 2007 Office System Driver, which allows you to read from and write to pre-existing files in either Office 2003 (.mdb and .xls) or the Office 2007 (*.accdb, *.xlsm, *.xlsx and *.xlsb) file formats.

Also, nowadays there are mechanisms like SQLite which are also very fast and light, especially for reasonably small databases, and also have the advantage of being cross-platform.


[hidden email]
May 17, 2011 9:15 AM


Oops…

 

Just found an old „fix“ of mine where I added #useBinding to AccessPlatform which answers false.

Without this, a package without comment publishes just fine J

 

I hope that the original problem that was fixed by that patch is solved… I will watch closely.

 

Sorry for the false alarm.

 

I would still like to know if using Access is advisable (I do like it because it is very light weight and fast).

 

Cheers,

                Christian

 


[hidden email]
May 14, 2011 4:53 AM


While moving to VW 7.8, I publish all Cincom code into a MSAccess Store.

Unfortunately, with the package [Com-Obsolete] Access throws an error (stack trace attached):

'An error occured when writing to the database.

[Microsoft][ODBC-Treiber für Microsoft Access] Syntaxfehler in Abfrageausdruck ''0x''.

No changes to the database have been commited'

(the second line in English would be something like:

                [Microsoft][ODBC driver for Micosoft Access] syntax error in expression “0x”.)

 

The failing SQL expression is:

                'INSERT INTO TW_Blob (primaryKey,blobType,blobData)  VALUES (265857,2,0x)'.

The 3rd parameter “0x” is created by the Glorp.InsertCommand (which is created by GlorpSession>>commandForHomogeneousRows: which is called from GlorpSession>>groupWrite: ) for an empty ByteArray.

 

Here the post error analysis gets a bit harder since all changes to the database are in one Set (UnitOfWork #newObjects) with 2062 elements L. 740 of those are StoreBlobs and one has indeed an empty ByteArray. Unfortunately I have no clue where this comes from…

 

So, I filtered the culprit out by temporarily patching Glorp and published. The result reconciles and compares (tried various Store settings) clean against the database… So, still no idea where the empty ByteArray comes from L

 

I guess there are two questions:

1. where does the empty Blob comes from?

2. should it be legal to insert an empty blob?

 

Cheers,

                Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Free forum by Nabble Edit this page