PDA

View Full Version : Alpha Runtime vs Active Link Tables


ABC123

rjbrown94
05-27-2014, 12:06 PM
I have both A5V12 developer and runtime installed on my computer. I use activelink tables to my SQL2008R2 server. I have written an append operation in xbasic to add a record to an activelink table. I've written it two ways... directly writing to the SQL server, and writing to the activelink table using the append operation. Both work very well on my computer in developer and runtime. So what's the problem? The computer right next to me is different. I installed Runtime only. Logged in as another user. The script gives me the error (attached) 38225. Now let me assure you, the other user has read/write permissions on the SQL table. And I've tried both scripts previously mentioned with the same error. Here's the catch... On MY computer, logged in as the other user and using Runtime, the script works PERFECTLY! So I'm convinced it's not a permission problem. Dear Alpha, is there another support program that you are using to write to the SQL tables? Is there a separate program I need to install on the other computer? I'm stumped. And lastly, All patches have been installed...

Peter.Greulich
05-27-2014, 01:23 PM
It does sound like a permission issue on the other machine. But you could go crazy and install the developer on the other machine and see if it works then. If so, there might be an RT issue. I assume you are not using a shadowed copy of the db on the 2nd machine? Not sure what that might do w. active-link tables.

rjbrown94
05-27-2014, 02:30 PM
I've been up and down the permission issue road on this for a couple of weeks (yes, I've been trying to solve this for that long). I am the one who sets up all of the permissions company wide in AD. I don't use computer based permissions. Everything is user based. I haven't installed developer yet. But I might try that just to see what happens. I swear the issue lies with needing a support program installed like a redistributable SQL client.

Ted Giles
05-28-2014, 08:46 AM
I know you won't want to try this, but create a vanilla .dbf table and see if the problem exists.
If so, it's probably an AD issue.
Is everything else working, like write and change in the SQL tables from the other machine?

rjbrown94
05-28-2014, 09:10 AM
I have previously tried your suggestion Ted and yes it works fine writing to a dbf. But it is definitely not an AD issue... I decided to create another Active Link table to a table in the same SQL database and try writing to it. The other computer has no problems writing to the new table. So I dug further. The table I'm having trouble with has 262 fields. 262!!! Yeah, don't blame me, I didn't make the table... Anyway, since I have no trouble writing to it using Developer and Runtime on my machine, and can't do it with Runtime only on the other machine. I'm thinking Runtime's AlphaDAO, which I believe is what communicates between SQL and Alpha, cannot write to tables that large. Would this be a Runtime bug?

Peter.Greulich
05-28-2014, 09:20 AM
Would this be a Runtime bug?

From your first post:

Both work very well on my computer in developer and runtime.

If that is true, I'm thinking it can't be a runtime bug.

Ted Giles
05-28-2014, 11:57 AM
Someone else had a problem using Append with that number of fields, and also there was a naming issue.
Doesn't explain the behaviour though.
Suggestion. Load the Dev version on the errant machine. Prove it works.
Remove the Dev version and try again.
If the system works ok, then something will have been left behind. If not, your assumption is correct and it is a RT buglet.
In which case, contact Selwyn@alphasoftware.com . He knows everything.

rjbrown94
06-03-2014, 09:30 AM
Well, I tried putting the developer version on the other computer. No go. I can write to every table in the database from any computer, except the super large fielded table. That one is writeable only on my computer. So here is a snapshot of all the SQL program installs on my computer. 38259

I have Visual Studio installed so that would explain a lot of them. I don't have any SQL databases on my computer, they are all installed on my SQL server. I can't help but think having SQL server installed is making the difference.

At this point I don't know what else to do except make the table a native Alpha table because that is the only way it works for everyone.

Ted Giles
06-03-2014, 10:27 AM
So you can write to all of the SQL tables EXCEPT the one with 262 fields on the RT only PC?
One way to test your theory of an ADO limitation would be to reduce the number of fields temporarily to less then 256, and try again.
I don't have access to an SQL 2008 server at present, so I can't test anything for you.
To keep the job going, your idea of converting to native dbf is a sound one. You could upsize if it works in Native to SQL later.

rjbrown94
06-04-2014, 02:28 PM
But it works in RT on my machine! I wonder if whatever SQL dll's I have is better than the version that comes with Alpha for use with AlphaDAO.

Ted Giles
06-04-2014, 02:50 PM
So have you tried loading SQL on the other PC and having another go? If you are allowed to that is.
There might well be incompatability. I presume you have run a compat check and run as admin first time around on the problem pc?
Hard to tell which DLL is the right one.

I am in the process of building a server and may be able to test this next week.
Else, export to Dropbox and give me a link. My email is in my signature.

rjbrown94
06-04-2014, 03:32 PM
Here is where Alpha needs to test this, I really don't have the time to do it. I get maybe 2 hours a day to work in Alpha as I wear 3 hats here at my job. The problem pc has admin rights and has no compatibility issues and I don't want to install SQL server on the pc as it is being used in production.

Ted Giles
06-04-2014, 04:00 PM
Only 3 hats. Gimme a break!

rjbrown94
06-04-2014, 04:14 PM
right... but I suck at multitasking so 3 is all I can handle :-)

Ted Giles
06-04-2014, 04:57 PM
Lol!

rjbrown94
06-19-2014, 05:02 PM
I finally discovered the problem. And I think it is a bug in Alpha Anywhere Runtime. I use SQL Server 2008 R2. You should be able to create this...

create a table in SQL with date fields. make sure they are just a date field, no "smalldatetime" fields.
Create an activelink table to your new SQL table
In AA developer, create a form with a grid to the new activelink table.
open up the form and enter or change the date in the grid and it works fine.
In AA runtime, open up the form and your dates do not show up at all in the grid.
In SQL, change the field definition to "smalldatetime" on your date fields.
Refresh the activelink definition.
In AA runtime, the dates show up and you can add and change them.

AA runtime DOES NOT SUPPORT "date" fields in SQL. They must be "smalldatetime" fields. This is a BUG because AA developer supports the "date" field.

Ted Giles
06-27-2014, 05:38 AM
Did you report this using the Bug Report Ric?