|
P: n/a
|
Hi All,
Is it possible to create a Make Table query in access (2.0 and 2003)
that creates the table into a SQL Server database?
Following the steps:
1- Create New Query
2- Set Query Type as Make-Table query
3- Enter table name
4- Click "Another Database", click Browse, then I cannot see anything
about data sources, ODBC, or SQL Server in the drop down box !!! only
few file types like *.mdb, *.adp, ...etc.
I already setup a ODBC data source.
If this is not supported from the GUI, then what is the SQL syntax? in
other words, SELECT * INTO Table1 IN "???" FROM Table2
Thanks for reading.
Mourad
| |
Share this Question
|
P: n/a
|
I am fairly certain that you can't create a table in Sql Server from an
Access mdb using ODBC. But you can certainly create a table on the
server from an Access mdb using ADO. First make a reference to the
Microsoft ActiveX Data Objects 2.5 (or higher) Library. From a code
module (you have to be in a code module to do this) go to the
Tools/References menu and select Microsoft ActiveX Data Objects 2.5 (or
2.6...) Library
And here is a code sample:
Sub CreateServerTable()
Dim cmd As New ADODB.Command
cmd.ActiveConnection = "Provider=SQLOLEDB; Data
Source=yourServer;Database=yourDB;UID=steve;passwo rd=abc;"
'--or if you have windows integrated security set
'cmd.ActiveConnection = "Provider=SQLOLEDB; Data
Source=yourserver;Database=yourDB;Trusted_Connecti on=Yes"
cmd.ActiveConnection.CursorLocation = adUseClient
cmd.CommandType = adCmdText
cmd.CommandText = "Create Table tbl1(rowID int Identity(1,1), fld1
varchar(50), Datefld datetime, fld3 varchar(50))
cmd.Execute
cmd.ActiveConnection.Close
End Sub
Rich
*** Sent via Developersdex http://www.developersdex.com *** | |
|
P: n/a
|
Rich P wrote:
I am fairly certain that you can't create a table in Sql Server from
an Access mdb using ODBC. [snip]
I can think if no reason why a passthrough query that executed a CREATE
TABLE statement would not work via ODBC. Assuming of course the user has
permissions to create tables.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com | |
|
P: n/a
|
lol nice lyle ill play the worlds smallest violin for you.
My question would be why are you trying to use a make table query.
The data in one is redundant as soon as you make it. It is only good
for maybe doing a series of reports on a very complex query that takes
a very long time to run.
| |
|
P: n/a
|
Thanks, Lord Kelvan and lyle fairfield for your valuiable input,
It's really worth to converting the Make-Table to pass-through
queries, however, it's worth mentioning the following:
1- The Make-Tables queries already exists, there are simply hundreds
of them! As I mentioned earlier, I'm moving from Access 2.0 back-end
to SQL Server.
2- The Make-Table queries join both Tables and Queries! The joined
queries further join tables and queries, and so on! The joined tables
could reside in both SQL Server and/or the local Access MDB file!! I'm
not sure how the ODBC/SQL Server will handle this! but it's worth to
try!
3- Losing the Query Design view for Pass Through queries is a little
discouraging!
This is a part of migrating an existing application, that was designed
using Access/File Server framework.
I will give it a shot to see how Access will handle this.
Thanks again,
Mourad
| |
|
P: n/a
|
I think you are likely to find the problems lie with creating SQL Server
tables from Access via ODBC. With some care, you may be able to create the
tables in SQL Server, and use Append Queries to add the data records to
them, instead of Make-Table Queries to create them with data.
Larry Linson
Microsoft Office Access MVP
"Mourad" <mo************@gmail.comwrote in message
news:47**********************************@i76g2000 hsf.googlegroups.com...
Thanks, Lord Kelvan and lyle fairfield for your valuiable input,
It's really worth to converting the Make-Table to pass-through
queries, however, it's worth mentioning the following:
1- The Make-Tables queries already exists, there are simply hundreds
of them! As I mentioned earlier, I'm moving from Access 2.0 back-end
to SQL Server.
2- The Make-Table queries join both Tables and Queries! The joined
queries further join tables and queries, and so on! The joined tables
could reside in both SQL Server and/or the local Access MDB file!! I'm
not sure how the ODBC/SQL Server will handle this! but it's worth to
try!
3- Losing the Query Design view for Pass Through queries is a little
discouraging!
This is a part of migrating an existing application, that was designed
using Access/File Server framework.
I will give it a shot to see how Access will handle this.
Thanks again,
Mourad
| |
|
P: n/a
|
Thanks Klatuu and Larry,
The motivation to move back-end to SQL Server is not mainly the file
size! The back-end is already split over many MDB file, with links to
front-end. I would say there are more than one motivation: one of them
is to get Access 2.0 and Access 2003 front-end applications to share
the same back-end data, which is version 2.0 mdb! For some reason we
are unable to run 2.0 and 2003 applications against the same 2.0 mdb
database!!! You may ask why don't upgrade all to 2003? Cannot! because
the application is huge, there are so many front and back-end's
databases, it is just too risky, and requires code freeze for a
while, ...etc. So one solution was to move the 2.0 back-end into SQL
Server, so front-end's applications connect using ODBC, and so we can
have 2.0 and 2003 apps share same data, then after that we can start
upgrade one front-end at a time. (sorry for the long details)
Larry,
I think Make-Table queries are a maintenance free approach! You don't
have to worry about any structure changes to the underlying joint
tables, things just work automatically. usually the tables created
using Make-Table query are temporary, in nature, that are used for
reports, ...etc. But I agree it also can be done using the Append
query, after deleting all rows!
I appreciate the tip for creating the right SQL syntax using both
Access and the Management studio.
Thanks,
Mourad
| |
|
P: n/a
|
None of these invalidates my suggestion. If you use Enterprise Manager to
create the tables in SQL Server, and link them, you should have no problem
_appending_ the Access records to the SQL tables. And, that will serve
exactly the same purpose -- creating and populating the SQL Server tables
with the data that is currently in Access.
And, given that
(1) you have not been able to use Make-Table queries to create SQL Server
tables, and
(2) no one here seems to have done so,
you are quite possibly wasting every minute that you spend trying to find a
way to do what seems, on the surface to be "an easier way".
Access 2.0 is, long since, "out of support", and there are a number of other
reasons to bring it up-to-date. Wishing you did not have to expend time and
energy to avoid the problems isn't going to make them go away. You can work
around some of them, but at the expense of making use of Access 2.0 more
complex. I was very fond of Access 2.0, but unless you retain some old,
limited-memory machines, plan on running it under a Virtual Machine so you
can limit memory to a size Access 2.0 can handle.
Larry Linson
Microsoft Office Access MVP
"Mourad" <mo************@gmail.comwrote in message
news:c5**********************************@m45g2000 hsb.googlegroups.com...
Thanks Klatuu and Larry,
The motivation to move back-end to SQL Server is not mainly the file
size! The back-end is already split over many MDB file, with links to
front-end. I would say there are more than one motivation: one of them
is to get Access 2.0 and Access 2003 front-end applications to share
the same back-end data, which is version 2.0 mdb! For some reason we
are unable to run 2.0 and 2003 applications against the same 2.0 mdb
database!!! You may ask why don't upgrade all to 2003? Cannot! because
the application is huge, there are so many front and back-end's
databases, it is just too risky, and requires code freeze for a
while, ...etc. So one solution was to move the 2.0 back-end into SQL
Server, so front-end's applications connect using ODBC, and so we can
have 2.0 and 2003 apps share same data, then after that we can start
upgrade one front-end at a time. (sorry for the long details)
Larry,
I think Make-Table queries are a maintenance free approach! You don't
have to worry about any structure changes to the underlying joint
tables, things just work automatically. usually the tables created
using Make-Table query are temporary, in nature, that are used for
reports, ...etc. But I agree it also can be done using the Append
query, after deleting all rows!
I appreciate the tip for creating the right SQL syntax using both
Access and the Management studio.
Thanks,
Mourad
| |
|
P: n/a
|
Thanks, larry, for the feed back,
Just wanted to make a correction, that, I actually COULD find the
right syntax to convert the Make-Table query to create the destination
table in SQL SQL Server! In addition, I've posted the syntax above so
it may benefit everyone! Here is it again:
"... set the query property "Dest Connect Str" to
"ODBC;DSN=DataSourceName;DATABASE=DBname;Trusted_C onnection=Yes;"
The result SQL query look like:
SELECT * INTO
[ODBC;DSN=DataSourceName;DATABASE=DBname;Trusted_Co nnection=Yes;].DstTable
FROM SrcTable;
Thanks again for your comments and feedback,
Mourad
| |
|
P: n/a
|
I just tried
SELECT * INTO
[ODBC;DSN=DataSourceName;DATABASE=DBname;Trusted_Co nnection=Yes;].DstTab
le
FROM SrcTable;
Sub MakeServerTblUsingODBC()
Dim strSql As String
strSql = "SELECT * INTO [ODBC;DSN=myDSN;DATABASE=myDB;Trusted_Connection
=Yes;].DstTable FROM tbl1;"
DoCmd.RunSql strSql
End Sub
This worked perfectly. I guess I was incorrected about stating that you
could not do this with ODBC. I don't really use ODBC - thus, what do I
know? But this is very cool indeed. I guess ODBC can perform just
about all the actions that ADO can perform. My only issue is the
continuous connection.
Rich
*** Sent via Developersdex http://www.developersdex.com *** | | This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 17865
- replies: 9
- date asked: Aug 27 '08
|
