The "trouble" starts when people try to overcome the "invalid argument" error (2GB maximum database size) by creating new tables in another database.I wouldn' t do that but that 's the way it is right now.I have searched for a way to track the query that created a table,but with no result whatsoever.Is there anyway to do that?The solution of looking all the "make table" queries doesn' t work.I would had to look all the queries in all the databases.

With a small research the conclusion is that there is no way to do that,track the query that created the table.Is that so?

Thanks in advance.

Track in what sense? Are you trying to FIND the query that was used to make a table?

Remember that no such query has to exist. I can do a design by grid to create a table and then populate the table with an append query. You could look for a maketable query forever and not find it.

I'm not sure I understand what you seek. I believe your comment about being unable to track a query is correct, but there is enough possible ambiguity that I'm not sure.

Can you try to explain what you really wanted? That way I would feel much better about any answer I could give you.

Further to Doc's reply you can also create and populate a table in VBA without using a query.

Ok.We all know that there are better ways to do things,but these are situations that I have not created i just found them there (my job).
I know you can create a query using VBA or populate the table with an append query but this is not the case here.
Unfortunately in order to override the maximum limit of mdb (2gb) someone started creating tables using make table queries in other databases in order to split the databases.Stupid but that 's what he thought.So from a.mdb he created a make table query that creates a table e.g "Table1" in b.mdb.When you open b.mdb you must be a magician or look all the queries in base a by browsing with the mouse pointer to see which query created the table "table1" .The tracking of the original query is essential for updates,maintenace,changes etc.If that way of thinking is applied to 4 or 5 bases, you see my problem.Maybe I hadn' t explained the problem so good.I am new here..
Thanks a lot for the answers, any other suggestions availiable?

You cannot do this after the fact. You can only guess.

Tables, queries, and macros do not include a context in which tracking events can be placed. VBA allows it, but the tracking still only applies to forms unless the VBA does its own tracking.

I regret to say that you cannot get there from here.

I'd also suggest that you report the problem to the boss and explain that the present solution is unfeasible and unmaintainable and maybe work out way to take the database off line and rebuild it the right way.

Even if somehow we managed to find a way to "track" the tables generated by queries, this still represents an flaw that is cancerous- it will get worse if you persist with that flaw.

I believe I agree with Banana completely on this one. The problem is not only technical, but systemic. This "someone" who played crazy table-split games to override table limits screwed you guys up and wasted lots of time.

First, if your tables exceed the 2 Gb limit, it is time to go Front-End/Back-End - with the back end being something other than Access.

Second, that something else probably WILL have the ability to track who does what to whom and when. Access, being a desktop tool that has been pushed WAY beyond its original design concept, is sorely lacking in robust security and auditing tools. Which is what you need for this situation.

Third, with 2 Gb of database and the way Access does things, you might find that your system's performance is less than ideal. Access works GREAT on smaller databases, but it has very limiting buffer sizes. That is, its internal I/O structures are limiting.

Something like an ORACLE (for Windows) or SQL Server solution might do better. I have no vested interest in either. A third solution that is neither of the above might just be what you find. Look around a bit before committing, but be prepared to make the change as quickly as you can. Otherwise, you'll have nothing but crap to wade through as that monstrosity just gets more bloated with time.

All I'm saying is that with that database size, to do anything serious in the way of warehousing or analysis, you have long ago graduated to the big leagues. As a front end, Access will work anywhere. When the back end gets this big, though, you are in heap big trouble.

I totally agree with your replies.Unfortunately the idea of an sql server was proposed but stacked somewher..I will take your advice on building it again,that was my idea too at the end.:):)
Don' t ever come to work in Greece and we are talking about one of the biggest firms...
Thanks a lot to you all.

FYI, if the cost of purchasing a SQL server or Oracle is what stopping you, look at MySQL or PostreSQL. Both are free and very capable.

The cost of an SQL server was denied? How about the recurring cost of salaries for the STAFF of extra support personnel required to tame this beast? Even if it cost $1000 for a single-use license, a burdened salary of a typical mid-level competent programmer would pay for this in ONE PERSON-WEEK! No more than two.