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

Dim c As String = "Data Source=SQL;Initial Catalog=AhavaOrder;Integrated Security=True"

Dim conn As New SqlConnection(c)
Dim cmd As SqlCommand = New SqlCommand("select * from tblItem", conn)
cmd.CommandType = CommandType.Text
Dim reader As SqlDataReader = cmd.ExecuteReader(CommandBehavior.CloseConnection)
Who is Participating?
try this:

fire up SDK command prompt from start menu.

caspol -q -machine -addgroup 1 -url file://h:/* FullTrust -name "H Drive"

where file://h:/* is the drive letter where the program is run from
What kind of Novell server?

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.
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?

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

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.
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!

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.
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... ;)
I totaly share your concerns about MS. I'm basically in prison by them.

I have confirmed that we are using IPX/SPX and Client32.
1)  What version and support pack level is the Client32?  Are any post-SP patches applied?
       - recommend using the latest 4.91 client, SP2, with any post-SP2 NWFS.SYS patch.
2)  Are you certain the client was installed "IPX only" or was it installed with both TCP/IP and IPX?
       - Recommend "IPX only."  Having both can confuse the client, and should only be used when transitioning to "pure IP."
3)  Was it installed "custom" and all client components for products/services you don't use deselected?
       - Recommend uninstall/reinstall, deselecting everything you don't know you have, especially NMAS.
4)  In the IPX NetBIOS compatible Transport (or whatever M$ calls it these days) is it set to "auto" or is a frame type and network number specified?  
       - Recommend specify frame type (match what the server has bound) and IPX network number (also match the server).  Leave the "internal IPX number" all zeroes.
5)  In the client properties, Advanced Settings tab, is "file caching" on or off?  Is "file commit" on or off?
       - Recommend "file caching" off and "file commit" on, unless the application requires OpLocks to function.  NOTE: this Could be the issue, and works hand-in-hand with a server-side setting I mention later...
6)  In the client properties, Advaned Login tab, is there an "NMAS authentication" setting?  Is it on or off?
       - Recommend setting it to "Off" in a pre-eDirectory-8.7.2 environment, and in 8.7.2 or higher, only set it ON if you >USE< NMAS methods.
7)  In the client properties, Advanced Settings tab, is "UNC Path Filter" on or off?
       - It should default to On.  If it's "Off" change it to "On."  This helps handle problems caused by how Microsoft now does service lookup when accessing a server via UNC path.
8)  Is the Novell client primary or secondary?  Is it first in the provider order list?  
      - Recommend it be primary, and make sure it's the primary network provider, too, to help the UNC path filter to work properly (among other things.)
9)  On the server, is "SET CLIENT FILE CACHING ENABLED" set to "OFF"?
      - Recommend it be set to "OFF" unless you have an application that requires Opportunistic Locking to function.  OpLocks can cause corruption with Excel and Access and FoxPro and the like.
10)  On the server, enter "version" at the console prompt and post the results, so I can give you more ideas.
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.
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?"
szx248Author Commented:
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.
szx248Author Commented:
I had done this but with not positive results
szx248Author Commented:

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 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>\<path to file>

So, if your H: drive is on Server1, Vol1, and is not map-rooted, your UNC path would be \\Server1\Vol1\act\order\op_cus
szx248Author Commented:
OK. So I tried this

'\\Ahava3\sys\act\order\op_cus.exp' (=h:\act\order\op_cus.exp)
as the filename and I got this error:

Could not bulk insert because file '\\Ahava3\sys\act\order\op_cus.exp' could not be opened. Operating system error code 67(The network name cannot be found.).

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

and the it gave me is this:
Could not bulk insert because file '\\old_serv\ahava3\sys\act\order\op_cus.exp' could not be opened. Operating system error code 53(The network path was not found.).

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\order\op_cus.exp

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.

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.
szx248Author Commented:
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?
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.
szx248Author Commented:
sp= stored procedure.
ah sorry, of course :)  I'm not a sql guru lol.

i doubt it...
Actually, it seems UNC path to a network device will work (but NOT mapped drives):

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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.