Solved Issues with Access 2019 (1 Viewer)

Andy74

Registered User.
Local time
Today, 13:46
Joined
May 17, 2014
Messages
98
Hello,

I worked for many year with Access 2010 on an application we use in our company, this is distributed to about 60 users. I recently changed my pc from WIndows 7 to Win 10 and Access 2019 (32 bit). The previous accdb seems to open correctly except that I got frequent unexpected crashes. For instance when I do some debugging sometimes even by just clicking on the immediate window, the application suddenly crushes, i.e. Access shuts down unexpectedly.

Is there anything I should do on the old accdb in order to make it fully compatible with the new Access 2019 (version 16)? For emergency I still work with Access 2010 on a remote desktop so I use that one to produce the accde, but it is not a long term policy.

Any suggestion is appreciated.

Andy
 

arnelgp

error reading drive A:
Local time
Today, 19:46
Joined
May 7, 2009
Messages
9,580
i'm not sure but you can try Creating a New 2019 db and import all your objects from the old db.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 07:46
Joined
Feb 19, 2002
Messages
28,998
Here are links to Access bug sites. You may find some help there.

 

Andy74

Registered User.
Local time
Today, 13:46
Joined
May 17, 2014
Messages
98
i'm not sure but you can try Creating a New 2019 db and import all your objects from the old db.
Thanks, I tried this but the error remains. It is a "conversion" error 3421 during a statement to assign a value to a recordset.

1593505473916.png


The line where it stops is the statement below. For some reason it doesn't read correctly the value on the "rstRead" recordset, while it did in the 2010 version.


1593505857226.png

The rstRead is Dao.Recordset.

Any further hint is much appreciated!

Andy
 

arnelgp

error reading drive A:
Local time
Today, 19:46
Joined
May 7, 2009
Messages
9,580
3421 as i googled, means datatype mismatch.
create a break point using debug.assert

...
rstWrite!Descrizione = rsrtRead!OPD_ORD_KEYDO
pause
debug.print vartype(rstWrite!qty), vartype(rstRead!qtaresidua)

if not same value, check each fieldtype.
 

Andy74

Registered User.
Local time
Today, 13:46
Joined
May 17, 2014
Messages
98
3421 as i googled, means datatype mismatch.
create a break point using debug.assert

...
rstWrite!Descrizione = rsrtRead!OPD_ORD_KEYDO
pause
debug.print vartype(rstWrite!qty), vartype(rstRead!qtaresidua)

if not same value, check each fieldtype.
Hello,

infact they show two different values:

The first is 2 (which is correctly a Null), the second is 8 which means it's string but it shouldn't. I am trying some workaround but the main issue is that Access keeps on crushing whatever I do ...
 

arnelgp

error reading drive A:
Local time
Today, 19:46
Joined
May 7, 2009
Messages
9,580
convert the other to Number:

rstWrite!qty = IIF(Len(rstRead!qtaresidua & "") > 0, Val(rstRead!qtaresidua), Null)
 

Andy74

Registered User.
Local time
Today, 13:46
Joined
May 17, 2014
Messages
98
thanks for the suggestion but it crashes at that expression. Even if I try to debug step by step and simply hover above the rstRead!qtaresidua variable it will crash.
 

Andy74

Registered User.
Local time
Today, 13:46
Joined
May 17, 2014
Messages
98
Hello, I finally found a workaround for this, but it took some time. Instead of assigning the rstRead variable to a query I created a temporary table and then assigned the rstRead to that temp table. If in the temp table the numeric values are set as "Long Integer" then it works, if they are left as "Decimal" it crushes. The first time I created the temp table as a copy from the original query all the numeric fields were set automatically as "decimal".

Anyway now it works. Thanks ArnelGP for the suggestions!
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 07:46
Joined
Feb 19, 2002
Messages
28,998
It would have helped us to know that you had a SQL Server that was recently updated to include BigInt fields. Newer versions of Access do support BigInt but if you set the option, you can NEVER use the app with an earlier version of Access. Unless you need a huge ID field, there is no need to use BigInt. I would change the BE to use Int (Long Integer in Access)
 

Andy74

Registered User.
Local time
Today, 13:46
Joined
May 17, 2014
Messages
98
Hello, in fact the application has two set of sources: one from SQL server and one from Oracle, the second one is mainly to read tables from our company production system. The query I mentioned actually involved the Oracle part. I will check if there was any change in the variable type in that source, but I don’t think so. Thanks for your suggestion.
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom