64bit vs 32bit ODBCPlugin Windows Invalid Precision Value

I have an application that stores graphic files (jpg, png, tiff, pdf) into an MS SQL Server database. All is good on 32 bit compiles. In fact, the 64 bit compile for OS X works perfectly, as well. However, the Windows 64 bit compile is the only one that fails with:

[Microsoft][ODBC SQL Server Driver] Invalid precision value

The code is pretty straight forward:

Dim rs As RecordSet
Dim DocImageString As String


’ do some code that sets DocImageString with a binary stream of the graphic file

’ SDB1 is the database connection previously opened in another Method using the ODBCPlugin

’ the ID field is the Primary Key field for the ARImages table

rs = SDB1.SQLSelect(“SELECT ID, InvoiceNo, Image FROM ARImages WHERE ID = 123”)
If rs <> Nil Then
If rs.EOF = False Then
rs.Edit
rs.Field(“Image”).StringValue = DocImageString
rs.Update
If SDB1.Error Then
MsgBox “SDB1.ErrorMessage”
End If
End If
rs.Close
End If

The above error message ("[Microsoft][ODBC SQL Server Driver] Invalid precision value") is what appears upon the rs.Update. Again, ONLY with the Windows 64-bit compile that is run on either Windows 10 connected to an MS SQLServer 2008 R2 Standard database or a Windows Server 2012 R2 with a SQL Server 2014 standard database. (the only test environments I have available to me for this).

Does any one have any ideas on this?

What’s the column type in the ID column?

ID = Integer
InvoiceNo = Integer
Image = Image (BLOB)

Feedback Case # 42506

Can you post the definition of the table being affected with this update ?
Just the SQL “create table” statement for it would be sufficient

[quote=246559:@Norman Palardy]Can you post the definition of the table being affected with this update ?
Just the SQL “create table” statement for it would be sufficient[/quote]
USE [Softbase]
GO

/****** Object: Table [dbo].[ARImages] Script Date: 02/11/2016 08:12:39 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[ARImages](
[CustomerNo] varchar NOT NULL,
[InvoiceNo] [int] NOT NULL,
[FileName] varchar NOT NULL,
[FilePath] nvarchar NULL,
[Image] [image] NULL,
[AddedBy] nvarchar NULL,
[DateAdded] [datetime] NULL,
[ChangedBy] nvarchar NULL,
[DateChanged] [datetime] NULL,
[ID] [int] IDENTITY(1,1) NOT NULL,
[ProcessedParts] [smallint] NOT NULL,
[ProcessedLabor] [smallint] NULL,
[ProcessedComments] [smallint] NULL,
[ProcessedCSS] [smallint] NULL,
[ProcessedPartsBy] varchar NULL,
[ProcessedLaborBy] varchar NULL,
[ProcessedCommentsBy] varchar NULL,
[ProcessedCSSBy] varchar NULL,
[IncludeWithInvoice] [smallint] NULL,
CONSTRAINT [PK__ARImages__358E4A2F253C7D7E] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

hmmm int is only 32 bits and I wonder if thats causing this

However, it works perfectly for Mac OS X… hmmmm

does seem odd but code for Windows & code for OS X could be different

right now its just a guess

[quote=246569:@Norman Palardy]does seem odd but code for Windows & code for OS X could be different

right now its just a guess[/quote]

The code must work for 32 bit and 64 bit users without having to change the schema of the database.

<https://xojo.com/issue/42506>

[quote=246576:@Terry Eutsler]The code must work for 32 bit and 64 bit users without having to change the schema of the database.
[/quote]
I dont disagree.
Just saying the plugin has code written for the Windows platform & the OS X platform and they may vary in how this is handled.
One may be trying to shove an int64 into the int field and the other may be using it as a 32 bit value in both cases.
One would fail, one would work.

[quote=246577:@Norman Palardy]I dont disagree.
Just saying the plugin has code written for the Windows platform & the OS X platform and they may vary in how this is handled.
One may be trying to shove an int64 into the int field and the other may be using it as a 32 bit value in both cases.
One would fail, one would work.[/quote]
My apologies. What I meant was, MY Xojo code must work for MY customers running both 32 & 64 bit versions of the compile while NOT having to change the database field types to int64. Does that make better sense?

I still dont disagree :stuck_out_tongue:
It should

[quote=246580:@Norman Palardy]I still dont disagree :stuck_out_tongue:
It should[/quote]
Wow! I guess that I’m screwed. My customers will not be happy about that. Thanks, though.

WHAT ???

I AGREE WITH YOU - I said that twice
You should NOT have to change your code or the schema

[quote=246580:@Norman Palardy]I still dont disagree :stuck_out_tongue:
It should[/quote]
As in “I dont disagree with you. Your code SHOULD work AS ISwithout changing the schema”

[quote=246586:@Norman Palardy]WHAT ???

I AGREE WITH YOU - I said that twice
You should NOT have to change your code or the schema

As in “I dont disagree with you. Your code SHOULD work AS ISwithout changing the schema”[/quote]
My double bad. Every time I read “I don’t disagree”, my brain told me “I don’t agree”. Now, I just feel like an idiot. My deepest apologies.

This is why people need more coffee :slight_smile:

lol… I haven’t had caffein in 14 years. Can’t afford to start now. I’d never be able to sleep! hehehe

well now we know the source of the problem
100% under caffeinated

Well, I still need a solution to this. My customers are forcing me to have to deal with this 64-bit bug issue with the ODBCPlugin.

Case #52926

The issue seems to be the Microsoft 64 bit ODBC driver. I have tried all versions of there driver and get the same error. I installed the Devart 64 bit ODBC driver and no longer get the error. The image is saved with no error using Devart driver in the 64 bit version of your software. You can download the trial version from Devart and try it yourself for 30 days.
I think you are using the Actual Tech ODBC driver on the Mac, so that is probably why you don’t get the error on the Mac version.
Thanks