December 2, 2007 at 12:00 pm
hi everybody
I've been working in the database field for 9 months
I started from very simple tables, to some sql stuff
And then I started studying SQL Server 2005 extensively until I took MCTS SQL Server 2005
During that time, I was building a database for a new company from scratch, and while I build it for them I keep on reading books and learning, and using this knowledge to upgrade the database
Recently, I could successfully migrate the back-end to SQL Server 2005, and after days of struggling I could connect the front end to it via ODBC in a LAN
My next step is connecting the database through the internet, so I just changed the server name in the DSN file to the address of the server, and opened the ports, but it didn't work....
Can you tell me what's the problem?
Is there a book that can help me do this thing?
I can buy any book and I have the will to learn, provided that I'll apply for MCITP Database Developer next months
Thank you..
December 2, 2007 at 1:17 pm
there is off course the free SQL Server Migration Assistant for Access (SSMA Access)
www.microsoft.com/sql/solutions/migration/access/default.mspx
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
December 2, 2007 at 1:25 pm
Microsoft SQL Server Migration Assistant (SSMA) for Access is a tool for migrating databases from Microsoft Access versions 97 through 2003 to Microsoft SQL Server 2005.
I'm using Access 2007 already
And the problem is not with migration
It's connecting the front-end to the back-end via the Internet...
December 3, 2007 at 8:09 am
Ahmed is right. It is a connection issue. Last year I was hooking up an Access 2003 to a SQL Server 2000 database. I found that when I tried to hook up using an ODBC link to a web server to refresh two small data tables it was extremely slow.
You should rethink the ODBC/Internet setup. I have used both ODBC and ADO in the above example and found on a local area network ADO is way faster than ODBC. The web developers that worked on the above project ended up using ADO.Net for their connection to the web based tables. But you might not want a web based system that would bypass Access altogether. http://www.access-programmers.co.uk/forums/ has been a good resource for me. There might be some posts on it related to your issues.
December 3, 2007 at 10:55 am
thanks for your reply
but i can't even make an odbc connection, i wish that it was slow only!!!
can you please point me to any type of resources, even if it was and expensive book/forum!
December 3, 2007 at 12:12 pm
Have you tested the ODBC setup? During the Create New or Editing of a connection you can run a test of the connection. I think when I set mine up it failed several times until I specified the database that I wanted to specifically open.
I also cannot remember exactly, but I think I could not open forms and view data with the internet ODBC. I could run Action Queries manually and that was about it.
You might want to visit the website I previously mentioned and post a question about ODBC over the internet and/or using an ADO connection through the internet.
In my case we gave up on ODBC and wrote a web application to use the web based SQL Server tables.
December 3, 2007 at 12:36 pm
I think that it sounds really strange!!
I think that this is a very important feature, and there's no easy implementation for it?!!
Do you think that using replication will be easy to accomplish?
PS: I already have MCTS SQL Server 2005, so I have a simple idea about that:)
December 4, 2007 at 4:53 am
I have previously been able to set this up between Access 2003 and SQL Server 2000 across the internet using ODBC. Had no trouble with forms etc. that has been mentioned already.
I did have to add an invisible control running a very quick query as a timed event every minute in order to keep the connection open, this avoided random disconnections.
Some suggestions, apologies if you have tried these already..
- It might be worth checking the ODBC connection is using the correct port number, if you changed the SQL Server port from the default, as many people do.
- Could it be a permissions issue - have you tested as SA just to see if it can connect?
- Are you using the SQL Native Client or the SQL Server ODBC driver.
- Do you get any particular error message when you run the 'test connection' option in ODBC that might give us a clue as to the problem?
December 4, 2007 at 6:31 am
I found the problem!!
Both test machines were using the same public ip, that's why it didn't connect
I think that I can't connect the source ip to the same ip, right?
December 4, 2007 at 3:44 pm
Ahmed Yarub Hani (12/4/2007)
I found the problem!!Both test machines were using the same public ip, that's why it didn't connect
I think that I can't connect the source ip to the same ip, right?
Correct, but before you keep going - you DO realize what you're implementing right now, right? You're exposing your SQL 2005 server to the internet - meaning you've now opened a door to your data that ANYONE can use.
That means that anyone who happens to scan for SQL connections on the Web will eventually find your server(and yes - there are lots of scans going on to find low-hanging fruit like that for hacks). Thanks to the door you have open - they will be free to keep hammering on it with whatever tools they have until they get through.
Tell me - how much is that data worth, anyway? How much would the company stand to lose when that data is compromised?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 5, 2007 at 4:39 am
When I set up an Access to SQL system over the internet a couple of years ago I had the help of a network engineer who did the firewall config for me. He said that he had made it secure by blocking all tcp/ip connectivity except that originating from the required domain.
I trusted the guy at the time because (a) it was his area of expertise, not mine (b) it was his job to configure tcp/ip, routing, etc.
The previous post has got me thinking - is there anything further I should have done to enhance the security, beyond changing the port address at SQL Server (2000) level and configuring permissions? Was I correct to trust the network guy to configure the lower level tcp/ip security?
If anyone has done this before, is there a best practice guide you would recommend?
thanks
Paul
December 5, 2007 at 8:22 am
Let's see if we can tweak Brian to post in here by using one of his recent buzzwords - protection in depth. He could probably get us a lot farther than I can.
Bottom line though - you need protection on a LOT of different aspects:
- protect the channel. If the connection between you and the server is wide open - you open yourself up to a man in the middle attack. All someone has to do it monitor the traffic between you and the server, and they'll either get your data, or the ability to log into the server as you, or both. Encrypt the communication channel using some decent VPN tunnelling, preferrably AES, preferrably split tunnelled.
- protect the ports. Don't use the default ports for damn near anything. Rotate them on a regular basis. Allowing only specific machines (preferrably by some type of authkey rather than by MAC or by IP) is also worthy. Block admin ports.
- enforce strong authentication. We use split authentication for remote access: one set for getting through the firewall, and one for your netowkr credentials. DON't set up your firewall to take your network credentials, and DON'T map your firewall credentials to your network credentials.
- don't expose anything admin-related. Even here - I would set up a Web Service to allow for some data retrieval, but don't allow for any direct access for anything admin-related.
Now - you can't usually get ALL of that into play, but several are a lot stronger than just one.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply