szx248
asked on
HELP - Novell & .Net & MS SQL Server?
I am having a problem with this VB.NET code when trying to connect to SQL Server.
At home it works, at work there are prolbems.
Home computer is a stand alone computer runninw Window XP and SQL Server 2000.
Work computer is a Novell Network made up of:
Novell server
MSSQL Server 2000
Citrix Server
This code works when I run a copy of the program that is on the Citrix or SQL Server drive, but if run from a Novel drive (no matter which computer I’m running it from) it fails
This is the error that I get:
Application attempted to perform an operation not allowed by the security policy. To grand this application the required permission, contact your system administrator, or use the Microsoft .NET Framework Configuration too.
Request for the permission of type
‘System.Data.SqlClient.Sql
Dim c As String = "Data Source=SQL;Initial Catalog=AhavaOrder;Integra
Dim conn As New SqlConnection(c)
Dim cmd As SqlCommand = New SqlCommand("select * from tblItem", conn)
cmd.CommandType = CommandType.Text
cmd.Connection.Open()
Dim reader As SqlDataReader = cmd.ExecuteReader(CommandB
reader.Read()
MsgBox(reader.Item(0))
At home it works, at work there are prolbems.
Home computer is a stand alone computer runninw Window XP and SQL Server 2000.
Work computer is a Novell Network made up of:
Novell server
MSSQL Server 2000
Citrix Server
This code works when I run a copy of the program that is on the Citrix or SQL Server drive, but if run from a Novel drive (no matter which computer I’m running it from) it fails
This is the error that I get:
Application attempted to perform an operation not allowed by the security policy. To grand this application the required permission, contact your system administrator, or use the Microsoft .NET Framework Configuration too.
Request for the permission of type
‘System.Data.SqlClient.Sql
Dim c As String = "Data Source=SQL;Initial Catalog=AhavaOrder;Integra
Dim conn As New SqlConnection(c)
Dim cmd As SqlCommand = New SqlCommand("select * from tblItem", conn)
cmd.CommandType = CommandType.Text
cmd.Connection.Open()
Dim reader As SqlDataReader = cmd.ExecuteReader(CommandB
reader.Read()
MsgBox(reader.Item(0))
the Novell is Netware 5.00.10
Windows is Windows Server 2003 Standard Edition sp1
Yes, when I said SQL Drive I meant Windows Drive on the same PC that is running SQL Server.
>Try adding the NetWare server into your Internet Explorer "trusted" zone.
How would this effect the LAN?
Windows is Windows Server 2003 Standard Edition sp1
Yes, when I said SQL Drive I meant Windows Drive on the same PC that is running SQL Server.
>Try adding the NetWare server into your Internet Explorer "trusted" zone.
How would this effect the LAN?
Well, the security hotfixes released over the past few months has screwed up many things, under the guise of the "safer" security policies. The workaround from Microsoft is to add whatever to the trusted zone.
That's assuming that you're using TCP/IP to connect to NetWare, which is the native protocol starting with NetWare 5, which was released about 7 or 8 years ago, and is considered obsolete (it's the same vintage as NT4.)
However, if you're using IPX/SPX, that may not apply. What I'd look at in that case is, are you using the Novell Client32 to log in to NetWare or are you using the crapware(tm) client that comes with Windows.
additionally, using cutting-edge Microsoft technologies with ancient non-Microsoft technologies and expecting it to work smoothly is kind of a crapshoot, since Microsoft is notorious for breaking compatibility even with their own obsolete stuff, never mind their track record for breaking compatibility with competitor products.
Just wait 'til Vista comes out and breaks everything you're running on now, including Windows 2003.
That's assuming that you're using TCP/IP to connect to NetWare, which is the native protocol starting with NetWare 5, which was released about 7 or 8 years ago, and is considered obsolete (it's the same vintage as NT4.)
However, if you're using IPX/SPX, that may not apply. What I'd look at in that case is, are you using the Novell Client32 to log in to NetWare or are you using the crapware(tm) client that comes with Windows.
additionally, using cutting-edge Microsoft technologies with ancient non-Microsoft technologies and expecting it to work smoothly is kind of a crapshoot, since Microsoft is notorious for breaking compatibility even with their own obsolete stuff, never mind their track record for breaking compatibility with competitor products.
Just wait 'til Vista comes out and breaks everything you're running on now, including Windows 2003.
I hear you loud and clear about the hotfixes, etc.
I do think that we are using TCP/IP to connect to NetWare. I dont't know about Novell Client32, I will check on that tomorrow.
I have noticed that I have the same problem in SQL Query Analyzer - I tried doing a Bulk Insert from a Novell drive and it couldn't read from there!
I do think that we are using TCP/IP to connect to NetWare. I dont't know about Novell Client32, I will check on that tomorrow.
I have noticed that I have the same problem in SQL Query Analyzer - I tried doing a Bulk Insert from a Novell drive and it couldn't read from there!
Sounds like a configuration issue to me, unless it's a version incompatibility between 2K3/.Net and 5.0. Hard to say without details on the configuration including client, version, protocols, whether any "tweak" settings were put in place, etc.
That's in addition to whatever security policy tweaks might be in order to work around the recent hotfix-induced issues.
Sometimes it's as simple as NetWare being installed with both IP and IPX, and the client being installed with the default "typical" configuration, but with both IP and IPX chosen, or how the caching/opportunistic locking settings are configured.
It could be as simple as a support pack, or a TCP/IP patch, or who knows what? That's what makes it a complex troubleshooting problem - you have to know where you're at to determine where to go next.
The more info you can get, the better we can help you. I know it's sometimes hard for a developer to know what details on the "plant and equipment" are important from a Network Administrator troubleshooting perspective, so maybe you could have your network guru look over your shoulder while we work this out.
That's in addition to whatever security policy tweaks might be in order to work around the recent hotfix-induced issues.
Sometimes it's as simple as NetWare being installed with both IP and IPX, and the client being installed with the default "typical" configuration, but with both IP and IPX chosen, or how the caching/opportunistic locking settings are configured.
It could be as simple as a support pack, or a TCP/IP patch, or who knows what? That's what makes it a complex troubleshooting problem - you have to know where you're at to determine where to go next.
The more info you can get, the better we can help you. I know it's sometimes hard for a developer to know what details on the "plant and equipment" are important from a Network Administrator troubleshooting perspective, so maybe you could have your network guru look over your shoulder while we work this out.
Regarding bulk insert - I used to work at a place that used what once was current M$ stuff - VB6 and MSSQL 7 on NT4 - and we did bulk loads from NetWare 5 all the time. Don't know how well that relates to bulk insert using the SQL Query Analyzer, but...
Just thought I'd pass that on, to show that it wasn't always such a big issue having a mixed NetWare/Windows environment.
This may be evidence of what the problem is with Microsoft not fully disclosing server communication APIs - the "big stink" in the EU antitrust decision that M$ is appealing as we speak. They are notorious for changing things just to break interoperability with non-Microsoft products. If it used to work, why doesn't it work now? What changed? - Microsoft products were "upgraded," that's what.
I thought upgrades were supposed to make things work better... ;)
Just thought I'd pass that on, to show that it wasn't always such a big issue having a mixed NetWare/Windows environment.
This may be evidence of what the problem is with Microsoft not fully disclosing server communication APIs - the "big stink" in the EU antitrust decision that M$ is appealing as we speak. They are notorious for changing things just to break interoperability with non-Microsoft products. If it used to work, why doesn't it work now? What changed? - Microsoft products were "upgraded," that's what.
I thought upgrades were supposed to make things work better... ;)
I totaly share your concerns about MS. I'm basically in prison by them.
Also
I have confirmed that we are using IPX/SPX and Client32.
Also
I have confirmed that we are using IPX/SPX and Client32.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This is usually down the the .net framework security settings. We had the same problem using VS.Net2003 on XP clients with students' home directories residing on nw6.5 servers. In control panel, admin tools, .net framework wizards, adjust the .net security to give full trust to your local intranet. Then it should run just fine without complaining.
If you need to push it out to lots of machines there's a command line utility that comes with the .net framework you can call via a zen app.
If you need to push it out to lots of machines there's a command line utility that comes with the .net framework you can call via a zen app.
Cool.
shineon has jumped the gun. I agree with alextoft -- we had exactly the same issue. Can't remember what the command line tool is called, but it's in the visual studio directory somewhere. Do a search on google and you'll find HEAPS of stuff on this, it's not a netware issue, it's a visual studio not liking network drives issue.
"jumped the gun?"
ASKER
ShineOn
thanks for the extensive reply
>> On the server, enter "version" at the console prompt and post the results, so I can give you more ideas.
What software do I need to run to get this info?
thanks for the extensive reply
>> On the server, enter "version" at the console prompt and post the results, so I can give you more ideas.
What software do I need to run to get this info?
Do you not have physical access to the NetWare server?
You enter "version" to the "colon" prompt.
You enter "version" to the "colon" prompt.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I had done this but with not positive results
ASKER
Floyd99,
Actualy I ran this caspol about a week before posting here and it didn't seem to effect anything. I re-ran it now exactly as you wrote it here and the vb.net programs work!!!!!!! this of course is great news. But - I'm not sure I mentioned this here - the SQL Server (using query analyzer, I'm sure it must be the same if it were sp) when I try to fetch a file from the Novel drive (in my case it's the H: drive) does not work. I get this error:
Could not bulk insert because file 'h:\act\order\op_cus.' could not be opened. Operating system error code 3(The system cannot find the path specified.).
So the caspol certainly fixed one major problem, but I am still left with the SQL piece.
I will increase the points to reflect part of the huge effort people here have been making and the help they have been giving me. Perhaps you all might have some solution for the SQL server.
Actualy I ran this caspol about a week before posting here and it didn't seem to effect anything. I re-ran it now exactly as you wrote it here and the vb.net programs work!!!!!!! this of course is great news. But - I'm not sure I mentioned this here - the SQL Server (using query analyzer, I'm sure it must be the same if it were sp) when I try to fetch a file from the Novel drive (in my case it's the H: drive) does not work. I get this error:
Could not bulk insert because file 'h:\act\order\op_cus.' could not be opened. Operating system error code 3(The system cannot find the path specified.).
So the caspol certainly fixed one major problem, but I am still left with the SQL piece.
I will increase the points to reflect part of the huge effort people here have been making and the help they have been giving me. Perhaps you all might have some solution for the SQL server.
A novel is a long work of fiction ;)
That said, SQL query functions are generally relative to the SQL server, so if the H: drive is a mapped drive and not a "real" local-to-the -server drive, then you'll have this issue.
Use the UNC path instead of the mapped drive.
When doing UNC path to NetWare, the notation is \\<servername>\<volume>\<p
So, if your H: drive is on Server1, Vol1, and is not map-rooted, your UNC path would be \\Server1\Vol1\act\order\o
That said, SQL query functions are generally relative to the SQL server, so if the H: drive is a mapped drive and not a "real" local-to-the -server drive, then you'll have this issue.
Use the UNC path instead of the mapped drive.
When doing UNC path to NetWare, the notation is \\<servername>\<volume>\<p
So, if your H: drive is on Server1, Vol1, and is not map-rooted, your UNC path would be \\Server1\Vol1\act\order\o
ASKER
OK. So I tried this
'\\Ahava3\sys\act\order\op
as the filename and I got this error:
Could not bulk insert because file '\\Ahava3\sys\act\order\op
But I am not sure what UNC should be. When I in Explorer under My Computer I get this for the H: drive:
Old_serv on 'Ahava3\Sys' (H:)
So I tried this for the UNC
\\old_serv\ahava3\sys\act\
and the it gave me is this:
Could not bulk insert because file '\\old_serv\ahava3\sys\act
Maybe I'm simply not entering the UNC corrrectly.
'\\Ahava3\sys\act\order\op
as the filename and I got this error:
Could not bulk insert because file '\\Ahava3\sys\act\order\op
But I am not sure what UNC should be. When I in Explorer under My Computer I get this for the H: drive:
Old_serv on 'Ahava3\Sys' (H:)
So I tried this for the UNC
\\old_serv\ahava3\sys\act\
and the it gave me is this:
Could not bulk insert because file '\\old_serv\ahava3\sys\act
Maybe I'm simply not entering the UNC corrrectly.
When you see, in Windows Explorer, "blah on 'foo\bar' (H:)" it means that the server/volume/path is "foo\bar" and the folder/share on that server/volume that's mapped as H: is "blah." The UNC would be "\\foo\bar\blah"
You should try: \\ahava3\sys\Old_serv\act\
To double-check, go to Windows Explorer, My Network Places, select "Novell Connections." If you see the server, expand it to see the volumes; if not, expand the tree to find the context of the server, locate the server, and expand it to see the volumes.
When you find your server/volume, look to see what folders there are underneath it. You'll probably see, on server ahava3, sys volume, a folder called "old_serv" that has the \act\order... etc. That would prove my theory to be correct.
No offense meant, szx248, but I must say, off-topic, that I'm not altogether surprised. Here's yet another example of what seems to be a trend: companies that let their NetWare languish also tend not to employ "best practices" by keeping user data off the SYS volume. "Admin 101" stuff. They tend also to be of the "we must be a Microsoft shop!" mentality and more often than not end up having a NetWare server "just there, because it works" in an otherwise all-Redmond environment... So sad, because it usually means they're not employing "best practices" in their Windows configuration either.
You should try: \\ahava3\sys\Old_serv\act\
To double-check, go to Windows Explorer, My Network Places, select "Novell Connections." If you see the server, expand it to see the volumes; if not, expand the tree to find the context of the server, locate the server, and expand it to see the volumes.
When you find your server/volume, look to see what folders there are underneath it. You'll probably see, on server ahava3, sys volume, a folder called "old_serv" that has the \act\order... etc. That would prove my theory to be correct.
No offense meant, szx248, but I must say, off-topic, that I'm not altogether surprised. Here's yet another example of what seems to be a trend: companies that let their NetWare languish also tend not to employ "best practices" by keeping user data off the SYS volume. "Admin 101" stuff. They tend also to be of the "we must be a Microsoft shop!" mentality and more often than not end up having a NetWare server "just there, because it works" in an otherwise all-Redmond environment... So sad, because it usually means they're not employing "best practices" in their Windows configuration either.
I've had this problem as well... When I checked the doco for SQL, the bulk insert requires the file to be local to the SQL server , not on a network drive.
So what I do is as part of the script, I use FTP and grab the file from the netware server (or whatever box it needs to come from), and dump it onto the C:\TEMP of the SQL box. The bulk insert command then works a treat because the file is sitting on the local disk.
So what I do is as part of the script, I use FTP and grab the file from the netware server (or whatever box it needs to come from), and dump it onto the C:\TEMP of the SQL box. The bulk insert command then works a treat because the file is sitting on the local disk.
Actually, now that I think about it, I do the reverse - I installed a shareware FTP program (ftpzilla or something its called), on the SQL Server.. then my scripts FTP TO the sql box. It's pretty easy to do, completely automated, and gets around the problem easily and cleanly.
Hope this helps.
Hope this helps.
ASKER
you can call the ftp from within a sp?
is there any way to simply copy a file from one drive to another in a sp?
is there any way to simply copy a file from one drive to another in a sp?
sorry, not sure what you mean by SP.
depends what you're trying to accomplish. In my environment, I've got a batch file set up using windows scheduler, and the first thing it does is using Perl & LDAP, extracts user data from NDS, converts the LDIF to CSV, massages the results a bit, then the second thing it does is FTP's the file to the SQL server, and then finally it runs osql , runs the bulk insert and then does the SQL part of stuff.
depends what you're trying to accomplish. In my environment, I've got a batch file set up using windows scheduler, and the first thing it does is using Perl & LDAP, extracts user data from NDS, converts the LDIF to CSV, massages the results a bit, then the second thing it does is FTP's the file to the SQL server, and then finally it runs osql , runs the bulk insert and then does the SQL part of stuff.
ASKER
sp= stored procedure.
ah sorry, of course :) I'm not a sql guru lol.
i doubt it...
i doubt it...
Actually, it seems UNC path to a network device will work (but NOT mapped drives): https://www.experts-exchange.com/questions/21855033/Bulk-Insert-and-Permissions.html
Per the info in that Q, you should make sure the SQL Server security account has rights to the file/folder - it doesn't use the logged-in user account for that access.
This may not work on a NetWare 5.0 box, 'cause NFAP is only available on 5.1 and up IIRC, but if it's an issue of using M$-specific client file access, you'd need to set it up as a "share" using NFAP/CIFS.
Per the info in that Q, you should make sure the SQL Server security account has rights to the file/folder - it doesn't use the logged-in user account for that access.
This may not work on a NetWare 5.0 box, 'cause NFAP is only available on 5.1 and up IIRC, but if it's an issue of using M$-specific client file access, you'd need to set it up as a "share" using NFAP/CIFS.
Novell is a company that makes several software products, including more than one server OS.
What version of which NetWare or OES or Linux server, with what support pack, makes a difference. How the client is connecting makes a lot of difference, too. How things are configured also make a difference.
Additionally, if you're running WinXP SP2 with the latest security hotfixes, a lot of applications that used to work fine in a non-SILO-Windoze environment are now broken (supposedly with the intent of fixing vulnerabilities.)
By the way, there is no such thing as a "SQL Server drive." You may mean a Windows server drive. MSSQL is a DBMS product, it doesn't present file services to a network. Same with a "Citrix drive" - Citrix is thin-client presentation services, not file services, so a drive on a Citrix session could be anything from a Windows share to a NetWare volume.
If you're having secrity-policy-related "permissions" issues, it's probably not just from having it on a NetWare drive, it's probably the new DEP or "Safer" stuff that's in the latest SP/hotfixes for XP, or, once again, Microsoft intentionally breaking things that aren't "all Windows all the time."
Try adding the NetWare server into your Internet Explorer "trusted" zone.